RFI_No._25-280-001-Product_Demonstration_Scripts.xlsx
XLSX spreadsheet 1 MB Posted
- Attached to
- RFI No. 25-280-001 entitled "California Wetland and Riparian Area Protection Portal" (CalWRAPP)
- Solicitation number
- 25-280-001
- Issued by
- Alameda County, Alpine County, Amador County, Butte County, Calaveras County, Colusa County, Contra Costa County, Del Norte County, El Dorado County, Fresno County, Glenn County, Humboldt County, Imperial County, Inyo County, Kern County, Kings County, Lake County, Lassen County, Los Angeles County, Madera County, Marin County, Mariposa County, Mendocino County, Merced County, Modoc County, Mono County, Monterey County, Napa County, Nevada County, Orange County, Placer County, Plumas County, Riverside County, Sacramento County, San Benito County, San Bernardino County, San Diego County, San Francisco County, San Joaquin County, San Luis Obispo County, San Mateo County, Santa Barbara County, Santa Clara County, Santa Cruz County, Shasta County, Sierra County, Siskiyou County, Solano County, Sonoma County, Stanislaus County, Sutter County, Tehama County, Trinity County, Tulare County, Tuolumne County, Ventura County, Yolo County, Yuba County, Alameda City, Alpine Village CDP, Amador City, Amador Pines CDP, Sutter Creek City, Butte Creek Canyon CDP, Butte Meadows CDP, Butte Valley CDP, Rancho Calaveras CDP, Colusa City, Contra Costa Centre CDP, Auburn Lake Trails CDP, El Dorado Hills CDP, Placerville City, South Lake Tahoe City, Fresno City, Kingsburg City, Orange Cove City, San Joaquin City, Shaver Lake CDP, Blue Lake City, Humboldt Hill CDP, Imperial City, Alta Sierra CDP, China Lake Acres CDP, Glennville CDP, Inyokern CDP, Kernville CDP, Lake Isabella CDP, Lake of the Woods CDP, Lakeside CDP, Hidden Valley Lake CDP, Lakeport City, Lower Lake CDP, North Lakeport CDP, Upper Lake CDP, East Los Angeles CDP, Elizabeth Lake CDP, Lake Hughes CDP, Lake Los Angeles CDP, Lakewood City, Los Angeles City, Marina Del Rey CDP, Monterey Park City, San Marino City, Sierra Madre City, Bass Lake CDP, Madera City, Madera Acres CDP, Madera Ranchos CDP, Yosemite Lakes CDP, Corte Madera Town, Lucas Valley-Marinwood CDP, Marin City CDP, Lake Don Pedro CDP, Mariposa CDP, Mendocino CDP, Merced City, University of California-Merced CDP, Lake City CDP, Crowley Lake CDP, June Lake CDP, Mammoth Lakes Town, Mono City CDP, Twin Lakes CDP, Virginia Lakes CDP, Marina City, Monterey City, Napa City, Lake of the Pines CDP, Lake Wildwood CDP, Nevada City, Lake Forest City, Orange City, Kings Beach CDP, Bucks Lake CDP, Lake Almanor Country Club CDP, Lake Almanor Peninsula CDP, Lake Almanor West CDP, Lake Davis CDP, Plumas Eureka CDP, Canyon Lake City, Lake Elsinore City, Lakeland Village CDP, Lake Mathews CDP, Lake Riverside CDP, Lakeview CDP, Riverside City, Orangevale CDP, Sacramento City, Big Bear Lake City, Lake Arrowhead CDP, San Bernardino City, Silver Lakes CDP, Spring Valley Lake CDP, Alpine CDP, Imperial Beach City, Lake San Marcos CDP, Rancho San Diego CDP, San Diego City, San Diego Country Estates CDP, San Francisco City, Lake Nacimiento CDP, San Luis Obispo City, Emerald Lake Hills CDP, San Mateo City, South San Francisco City, Santa Barbara City, University of California-Santa Barbara CDP, Santa Clara City, Santa Cruz City, Lakehead CDP, Shasta CDP, Shasta Lake City, Sierra Brooks CDP, Sierra City CDP, Sierraville CDP, Lake Shastina CDP, Mount Shasta City, Sonoma City, Sonoma State University CDP, Monterey Park Tract CDP, Orange Blossom CDP, Sutter CDP, Yuba City, Lake California CDP, Rancho Tehama Reserve CDP, Tehama City, Trinity Center CDP, Trinity Village CDP, East Tulare Villa CDP, Tulare City, Mono Vista CDP, Phoenix Lake CDP, Pine Mountain Lake CDP, Sierra Village CDP, Tuolumne City CDP, Lake Sherwood CDP, West Sacramento City, Yolo CDP, Plumas Lake CDP, California
About this file
This file contains product demonstration scripts and evaluation criteria for two separate RFI processes related to the State Water Board's CalWRAPP Project: RFI No. 25-280-001 for a permit and application management system, and RFI No. 23-280-002 for a Financial Management System (FMS). The CalWRAPP Project demonstration (Phase 2, Event No. 25-280-001) requires vendors to demonstrate 16 functional capability areas across a maximum of 80 evaluation points, including user registration and profile management, application preparation and submittal, permit intake and review, public notice handling, inspection scheduling, compliance tracking, permit modification and closure, reporting and data management, document management, configurable business rules, workflow routing, transparency and reporting, historical tracking, customer relationship management, user interface capabilities, and overall presentation quality. The FMS demonstration (RFI No. 23-280-002) encompasses 20 functional demonstration areas evaluated across a maximum of 50 points, including chart of accounts setup, accounting transaction flow, accounting period configuration, recurring ledger templates, manual journal entry processes, posting procedures, year-end processing, period closure and reopening, journal inquiry drill-down capabilities, reporting and inquiry functions, accounts receivable master file setup, invoice posting and printing, cash application functionality, short payment handling, collections tools, multi-customer payment processing, dunning letter procedures, NSF check handling, invoice modification, and system interface capabilities.
The evaluation methodology employs a three-point functional scoring system (0 = did not meet requirement, 2 = meets requirement, 3 = exceeds requirement) combined with a three-point usability scoring system (0 = cumbersome, 2 = usable, 3 = easy to use), with weighted scores calculated from both components. One vendor demonstration for the FMS component (Vendor 2) achieved a Phase 2 total score of 30.66 points out of the maximum 50 points available. A third vendor evaluation template is included but shows zero points and appears incomplete. The demonstrations are structured to assess vendor understanding of program requirements, proposed software capabilities, and experience with similar governmental applications.
View the file
Other files
| File | Type | Posted |
|---|---|---|
| RFI_No._25-280-001_-_RFI_Response_Worksheet.xlsx | XLSX spreadsheet | |
| Request_For_Information_No._25-280-001_CalWRAPP.pdf |
On GovTribe
Work with this file
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
Phase 2-COMPANY1 template
| CalWRAPP Project No. 3940-110 |
| Phase 2: Product Demonstration |
Event #: 25-280-001 Time Slot #: COMPANY
DATE (TIME)
| Vendor Product Demonstration Script: The following demonstration scripts cover critical requirements of the system. Vendors must demonstrate the typical functionality required by State Water Board program staff. The general outline for each script provides the information to demonstrate the desired functionality of the proposed system. | |
| Demonstration Script | Solution Demonstration: |
| Ability to meet stated requirements. Highlights features, relevance to business process and ease of use. Responses to questions from audience/evaluation panel. |
0-Did not meet expectation 1- Far below expectations 2- Below expectations 3- Meets expectations 4- Exceeds Expectations 5- Far Exceeds Expectations
| 1) Demonstrate User Registration and Profile Management | |
| a. Ability to provide external user registration via a secure web interface. (FR-1) | |
| b. Ability to allow secure upload of required documentation. (FR-2) | |
| c. Ability to collect and manage contact information and organization affiliation. (FR-3) | |
| d. Ability to provide self-service options for user to update profile information. (FR-4) | |
| e. Ability to auto-populate user transactions with profile and organization contact information. (FR-14) | |
| f. Ability to provide user a way to submit requests for pre-application consultations. (FR-9) | |
| g. Ability to provide an external unregistered user a way to submit general questions to staff. (FR-6, FR-8) | |
| 2) Demonstrate Application Preparation and Submittal | |
| a. Ability for applicant to input project-related information by filling out pre-determined fields and uploading required documents such as environmental reports (in PDF and MS Word formats) and geospatial data using templates. (FR-17, FR-18, FR-22) | |
| b. Ability to validate applicant inputs against pre-determined business rules. (FR-21) | |
| c. Ability to ensure all fields marked as mandatory are completed before submittal. (FR-23) | |
| 3) Demonstrate Application Intake, Review, and Permit Issuance | |
| a. Ability to accept new permit application from applicant. (FR-14) | |
| b. Ability to automate notification and routing of a pre-application consultation or new application and assignment to appropriate staff. (FR-10, FR-11, FR-19, FR-30, FR-31, FR-33) | |
| c. Ability to support internal review workflows, including tracking application status. (FR-35, FR-46) | |
| d. Ability for two-way communication within the system between staff and applicant, including requests for and receipt of additional information. (FR-34, FR-61, FR-85) | |
| e. Ability for staff and managers to upload permit decisions and documents, including setting future compliance requirements and deadlines. (FR-42) | |
| 4) Demonstrate Public Notice and Comment Handling | |
| a. Ability to publish limited application information or draft permits online for public access. (FD-2) | |
| b. Ability to accept public comments electronically. (FD-2) | |
| c. Ability for staff to review and manage comments. (FD-2) | |
| d. Ability to link the public comments to the relevant application record. (FD-2) | |
| 5) Demonstrate Inspection Scheduling and Management | |
| a. Ability to schedule inspections linked to specific permits. (FR-96) | |
| b. Ability to collect inspection data (including written, geospatial, and photographic data) in the field and in a disconnected state. Ability to export or interface with a third-party solution is acceptable. (FR-102) | |
| c. Ability to upload and attach inspection results, photos, checklists, or reports, including imports from third-party inspection applications used on mobile devices in a disconnected state. (FR-103, FR-104, FR-105, FR-106) | |
| d. Ability to notify applicant or permittee of upcoming inspections. (FR-97) | |
| e. Ability to maintain a list of scheduled inspections. (FR-98, FR-100, FR-101) | |
| f. Ability to flag and schedule records for future inspections. (FR-99) | |
| g. Ability to notify applicant or permittee of new inspection report results. (FR-110) | |
| 6) Demonstrate Permit Monitoring and Compliance Tracking | |
| a. Ability for staff and managers to track multiple permit records and their associated compliance deadlines. (FR-64) | |
| b. Ability to send automated notifications to permittee and assigned staff when deadlines are approaching or have passed. (FR-65) | |
| c. Abiliyt to accept permittee-submitted monitoring reports for staff review and approval. (FR-90) | |
| 7) Demonstrate Permit Modification and Closure | |
| a. Ability for permittee to submit closure or termination requests. (FR-116) | |
| b. Ability for staff to review and approve closure requests. (FR-117) | |
| c. Ability to archive or close permit records while retaining access to documentation and ability to reopen records. (FR-119) | |
| 8) Demonstrate Reporting and Data Management | |
| a. Ability to generate standard and custom reports for both internal and external permit tracking and program performance. (FR-66, FR-67, FR-69, FR-70) | |
| b. Ability to generate a public dashboard or summary report, and public dashboard or map, and a search function for viewing active and closed permit records. (FR-67, FR-69, FR-70) | |
| c. Ability to support exporting data to Excel, CSV, or other similar formats, to support open data efforts. (FR-80) | |
| d. Ability to provide dashboards or data visualization tools to staff and managers. (FR-62) | |
| e. Ability to send automated reminders to applicant, permittee, staff, and managers based on due dates or actions. (FR-45, FR-65) | |
| f. Ability to read from and write to the ArcGIS Enterprise Portal, including ingesting, editing, and managing geospatial (GIS) data, with geospatial visualizations and reports generated within the portal based on the collected data. (FR-16) | |
| g. Ability to enable staff and managers to aggregate and review geospatial and permit data, and to perform cross-analysis with data from other sources, in order to assess statewide trends and evaluate program effectiveness. (FR-39, FR-40) | |
| h. Ability to import data from external systems and update corresponding records based on record type and status (e.g., invoices due, fees paid). (FR-58) | |
| 9) Demonstrate the Ability to Transmit, Manage and Maintain Data and Documents | |
| a. Ability to create a configurable submission that includes machine readable data and documents as well as validation rules. | |
| b. Ability to create business rules for submission routing, review, and response generation. (FR-23, FR-79) | |
| c. Ability to access and approve data submissions an dchanges based on roles/permissions. (FR-27, FR-43) | |
| d. Ability to configure and apply data validation rules and ensure data integrity. (FR-21, FR-77) | |
| e. Demonstrate electronic content management capabilities, including any functionality for intake tagging, searching, filtering, and retrieving documents. (FR-32, FR-33) | |
| f. Ability to manage relationships between records and permitting actions through a user-friendly interface, to build a visualization for the linkage among records; allowing staff to modify the linkage if necessary. (FR-74, FR-95) | |
| 10) Demonstrate Configurable, Time-Bound Requirements (Business Rules), Including Both Standard/Recurring Requirements and Ad Hoc Requirements | |
| a. Ability to apply configurable requirements to application and permit records. (NFR-53, NFR-57, NFR-74) | |
| b. Ability to configure requirements in a no-code environment. | |
| c. Ability to connect requirement with submission fulfilling the requirement. | |
| d. Ability to maintain and retain hisotry of modifications to requirements. (NFR-77, NFR-78) | |
| 11) Demonstrate the Ability to Route Workflow | |
| a. Ability to create, monitor, and manage workflow routing based on type of record or request. (FR-35, FR-63, FR-98, FR-112, FR-117) | |
| b. Ability to create unique identifiers for each profile/record based on specific criteria and continue in a sequential order. (FR-73) | |
| c. Ability to adjust workflow routing and manually reassign individual workflow tasks, including deadlines where applicable, based on user roles and permissions. (FR-11, FR-32) | |
| 12) Demonstrate Transparency and Reporting | |
| a. Ability to monitor performance, provide end-to-end response time for transactions with the more load created, integrate with 3rd party tools. | |
| b. Ability to provide standard data extraction such as Application Program Interface (API) to allow data export/import to interfacing systems and exchange data using industry accepted standards (EDI, XML). | |
| c. Ability to provide database backup and recovery tools and strategies; encrypt and decrypt sensitive data by column, row, and/or field at rest and in use by application; data archival strategies. | |
| d. Ability to integrate with Business Intelligence/Data Warehouse tool, automate analytical reports generation, distribution of reports (FTP or email), and/or organize and automate select data publishing/export on a regular cadence. | |
| e. Ability of data catalog such as data lineage, structural/descriptive/administrative metadata, data curation, metadata curation, data governance, search capabilities, data quality monitoring, customization. | |
| f. Ability to verify postal address (including foreign addresses). | |
| 13) Demonstrate Historian | |
| a. Ability to track uer activities and all change history. | |
| b. Ability to retain history of previous submissions, including for closed records. (FR-24, FR-48) | |
| c. Ability to retain history of all communications within the system. (FR-81) | |
| 14) Demonstrate Customer Relationship Management with a Focus on Uses for Government | |
| a. Ability to manage and track interactions with applicants and permittees. | |
| b. Any features tailored for governmental use. | |
| c. Ability to disseminate information, log inquiries, route inquiries, store inbound/outbound inquires/responses, track responses, and associate grouped inquiries such as by requestor, topic, unique identifier, etc. | |
| d. Demonstrate case management functionality for complex issues including workflow routing, tracking, and case notes. | |
| e. Ability to perform analysis on information gathered by system and export information and results. | |
| 15) Demonstrate the Application's User Interface Capabilities | |
| a. Ability to manage automatic and manual job scheduling (i.e., batch jobs) including but not limited to the interface with automatic or internal user-initiated notification capabilities when a job completes successfully, unsuccessfully, or abnormally terminates. | |
| b. Ability to provide built-in application and system configuration tables accessible by all modules. | |
| c. Ability of mobile responsiveness across multiple operating systems and devices, i.e., iOS and Android. | |
| d. Ability to adhere to all modern web browsers, such as, but not limited to, Chrome, Edge, Safari, Firefox, etc. (NFR-466) | |
| e. Ability to provide customizable user portals including, but not limited to the ability ot customize menus, forms and UI look-and-feel, by internal user(s) and ability for staff to modify text on external-facing application pages. | |
| 16) Proposer presentation: Quality of overall presentation. Level of understanding of needs and scope of project. Ability to demonstrate experience and success with similar projects involving the proposed software solution. | |
| Phase 2 Total | |
| (Maximum 80 Points) | 0 |
Process Flow Summary
A. Pre-App
B. Submit App
C. Review App
D. Implementation
E. Enforcement
F. Inspection
G. Amendments
H. Data & Reporting
I. Closure
J. Billing
IGNORE Phase 2-Vendor 2
Phase 2: Product Demonstration Evaluation WaterTAP (WT) Project RFI No. 23-280-002
Time Slot #2: Vendor April x, 2024 (11:00 AM to 1:15 PM) Vendor Product Demonstration Script: The following demonstration scripts cover critical requirements of the system. Vendors must demonstrate the typical functionality required by State Water Board program staff. The general outline for each script provides the information to demonstrate the desired functionality of the proposed FMS system.
Phase 2: Product Demonstration Evaluation Financial Management Software (FMS) RFI No. 23-280-001
| Functional Score | Usabillity Score | Weighted Score |
| This field contains the score based upon how well the software meets the defined functional requirement. A 3-point system is to be used for scoring as follows: |
0-Did not meet requirement 2-Meets Requirement 3-Exceeds Requirement This field contains the ease of use score.
A 3 point system is to be used as follows:
0-Cumbersome 2-Usable 3-Easy to Use
| 1) Demonstrate the basic set-up of the chart of accounts. | 2-Meets Requirement | 3-Easy to Use | 1.88 |
| a. Length of account and support for alpha, numeric, and alpha-numeric values | |||
| b. Definition of structural elements within the ledger (number of segments allowed, etc.) | |||
| c. Availability of user defined account segments | |||
| d. Demonstrate how to add and change accounts | |||
| 2) Demonstrate the flow of accounting transactions into the ledger. | 2-Meets Requirement | 3-Easy to Use | 1.88 |
| a. Do entries first hit individual module ledgers, etc. | |||
| b. How/ when do items hit suspense or error | |||
| 3) Demonstrate the set-up of accounting periods within your system. | 2-Meets Requirement | 3-Easy to Use | 1.88 |
| a. Can A/R have a different definition of each accounting period than, for example, A/P? | |||
| b. What is the maximum number of accounting periods that can exist within a given accounting year? | |||
| 4) Demonstrate the creation of a recurring ledger template. | 2-Meets Requirement | 2-Usable | 1.25 |
| a. For an entry in which the accounts and amounts are both fixed | |||
| b. For an entry in which the accounts and amounts are defined but can be changed | |||
| 5) Demonstrate the process for entering a manual journal entry. | 3-Exceeds Requirement | 2-Usable | 1.88 |
| a. Discuss how transactions made by one individual can be separated from transactions entered by another | |||
| 6) Demonstrate the process for posting a journal entry. | 2-Meets Requirement | 2-Usable | 1.25 |
| a. Post the various entries made in the earlier parts of this demonstration (including that from item 7) | |||
| 7) Demonstrate or discuss the process for year-end processing. | 2-Meets Requirement | 2-Usable | 1.25 |
| a. Specifically address the system-wide resetting of various balances (e.g., customer year-to-date purchases, year-to-date account balances) | |||
| 8) Demonstrate or discuss the process for re-opening a closed period, entering a transaction, closing the period and rolling the transaction forward. | 3-Exceeds Requirement | 3-Easy to Use | 2.5 |
| a. Can multiple periods be open at any one time | |||
| b. Demonstrate the process for closing an accounting period | |||
| 9) Demonstrate the ability of your system to start with summary journal inquiries and then drill down to the individual transaction detail. | 2-Meets Requirement | 2-Usable | 1.25 |
| 10) Demonstrate the various reports and on-line inquiries available within your system. | 2-Meets Requirement | 3-Easy to Use | 1.88 |
| a. Customer payment history | |||
| b. Open AR's (positive balance) | |||
| c. AR's with credit balances | |||
| d. Reports listing payment details from AR batch | |||
| e. Misc. report of payments not posted to AR's | |||
| f. Write-offs | |||
| g. Revenue collected by income type | |||
| h. Inquiry to pull GL balances | |||
| i. User ability to create customized queries | |||
| j. Suspense report | |||
| k. Reports for all chart fields | |||
| 11) Briefly review some of the basic set-up of the master files within the accounts receivable module. | 2-Meets Requirement | 2-Usable | 1.25 |
| a. Customer master | |||
| b. Terms codes | |||
| 12) Post and print the various invoices | 2-Meets Requirement | 2-Usable | 1.25 |
| a. Demonstrate the process of re-printing an invoice to a customer, specifically addressing the ability to send the document using a variety of different means (e.g., fax, e-mail, EDI.) | |||
| 13) Demonstrate the cash application functionality available within your system. | 2-Meets Requirement | 2-Usable | 1.25 |
| a. Auto-matching, by invoice, oldest first, etc. | |||
| b. Miscellaneous cash receipts | |||
| c. Reverse a payment and reapply | |||
| 14) Demonstrate how your system handles the situation in which a customer short pays an invoice. | 2-Meets Requirement | 3-Easy to Use | 1.88 |
| a. Show how the resulting balance can be kept open and an appropriate balance due invoice created, printed and linked back to the original invoice, as well as the date the system uses for determining the aging of this balance due invoice | |||
| b. Show how the short payment can be written off and the methodology for handling which accounts are used as part of that write-off | |||
| 15) Demonstrate the tools provided by your system to aid in the collections process. | 2-Meets Requirement | 2-Usable | 1.25 |
| a. Collection call logs or notes | |||
| b. Automated system notification of credit personnel of past due invoices | |||
| c. User definable parameters for establishing grace periods, and generating late notices | |||
| d. Ability to reset or delete late notices generated in error | |||
| 16) Demonstrate how an check from an parent customer can be used to pay invoices from multiple child customers. | 2-Meets Requirement | 2-Usable | 1.25 |
| a. Linking of these customers | |||
| 17) Demonstrate the process for sending dunning letters to a customer. | 2-Meets Requirement | 2-Usable | 1.25 |
| a. Review the rules, etc. for determining whether / when a customer gets a dunning letter | |||
| 18) Demonstrate the process within your system for handling a customer check returned for NSF. | 2-Meets Requirement | 3-Easy to Use | 1.88 |
| a. Demonstrate the re-instatement of the receivable and how it now shows relative to the aging process | |||
| 19) Demonstrate how a user of your system would be able to modify AR invoices | 2-Meets Requirement | 2-Usable | 1.25 |
| a. Demonstrate how a user would place a invoice on hold and what the process would be to release the invoice from hold | |||
| b. Demonstrate the transaction of canceling or adjusting an invoice |
| 20) Demonstrate or explain your system's interface capabilities with other Systems | 2-Meets Requirement | 2-Usable | 1.25 | |
| a. Demonstrate that they can receive files from subsidiary systems | ||||
| b. Demonstrate ability to export and interface data to a ERP system | ||||
| c. Capability to export and update payment information and AR balances back to subsidiary systems | ||||
| Phase 2 Total | ||||
| (Maximum 50 Points) | 30.66 |
IGNORE Phase 2- Vendor 3
Phase 2: Product Demonstration Evaluation WaterTAP (WT) Project RFI No. 23-280-002
Time Slot #3: Vendor April x, 2024 (2:15 PM to 4:30 PM)
| Vendor Product Demonstration Script: The following demonstration scripts cover critical requirements of the system. Vendors must demonstrate the typical functionality required by State Water Board program staff. The general outline for each script provides the information to demonstrate the desired functionality of the proposed FMS system. | |||
| Demonstration Script | Functional Score | Usabillity Score | Weighted Scores |
| This field contains the score based upon how well the software meets the defined functional requirement. A 3-point system is to be used for scoring as follows: |
0-Did not meet requirement 2-Meets Requirement 3-Exceeds Requirement This field contains the ease of use score.
A 3 point system is to be used as follows:
0-Cumbersome 2-Usable 3-Easy to Use
| 1) Demonstrate the basic set-up of the chart of accounts. |
| a. Length of account and support for alpha, numeric, and alpha-numeric values |
| b. Definition of structural elements within the ledger (number of segments allowed, etc.) |
| c. Availability of user defined account segments |
| d. Demonstrate how to add and change accounts |
| 2) Demonstrate the flow of accounting transactions into the ledger. |
| a. Do entries first hit individual module ledgers, etc. |
| b. How/ when do items hit suspense or error |
| 3) Demonstrate the set-up of accounting periods within your system. |
| a. Can A/R have a different definition of each accounting period than, for example, A/P? |
| b. What is the maximum number of accounting periods that can exist within a given accounting year? |
| 4) Demonstrate the creation of a recurring ledger template. |
| a. For an entry in which the accounts and amounts are both fixed |
| b. For an entry in which the accounts and amounts are defined but can be changed |
| 5) Demonstrate the process for entering a manual journal entry. |
| a. Discuss how transactions made by one individual can be separated from transactions entered by another |
| 6) Demonstrate the process for posting a journal entry. |
| a. Post the various entries made in the earlier parts of this demonstration (including that from item 7) |
| 7) Demonstrate or discuss the process for year-end processing. |
| a. Specifically address the system-wide resetting of various balances (e.g., customer year-to-date purchases, year-to-date account balances) |
| 8) Demonstrate or discuss the process for re-opening a closed period, entering a transaction, closing the period and rolling the transaction forward. |
| a. Can multiple periods be open at any one time |
| b. Demonstrate the process for closing an accounting period |
| 9) Demonstrate the ability of your system to start with summary journal inquiries and then drill down to the individual transaction detail. |
| 10) Demonstrate the various reports and on-line inquiries available within your system. |
| a. Customer payment history |
| b. Open AR's (positive balance) |
| c. AR's with credit balances |
| d. Reports listing payment details from AR batch |
| e. Misc. report of payments not posted to AR's |
| f. Write-offs |
| g. Revenue collected by income type |
| h. Inquiry to pull GL balances |
| i. User ability to create customized queries |
| j. Suspense report |
| k. Reports for all chart fields |
| 11) Briefly review some of the basic set-up of the master files within the accounts receivable module. |
| a. Customer master |
| b. Terms codes |
| 12) Post and print the various invoices |
| a. Demonstrate the process of re-printing an invoice to a customer, specifically addressing the ability to send the document using a variety of different means (e.g., fax, e-mail, EDI.) |
| 13) Demonstrate the cash application functionality available within your system. |
| a. Auto-matching, by invoice, oldest first, etc. |
| b. Miscellaneous cash receipts |
| c. Reverse a payment and reapply |
| 14) Demonstrate how your system handles the situation in which a customer short pays an invoice. |
| a. Show how the resulting balance can be kept open and an appropriate balance due invoice created, printed and linked back to the original invoice, as well as the date the system uses for determining the aging of this balance due invoice |
| b. Show how the short payment can be written off and the methodology for handling which accounts are used as part of that write-off |
| 15) Demonstrate the tools provided by your system to aid in the collections process. |
| a. Collection call logs or notes |
| b. Automated system notification of credit personnel of past due invoices |
| c. User definable parameters for establishing grace periods, and generating late notices |
| d. Ability to reset or delete late notices generated in error |
| 16) Demonstrate how an check from an parent customer can be used to pay invoices from multiple child customers. |
| a. Linking of these customers |
| 17) Demonstrate the process for sending dunning letters to a customer. |
| a. Review the rules, etc. for determining whether / when a customer gets a dunning letter |
| 18) Demonstrate the process within your system for handling a customer check returned for NSF. |
| a. Demonstrate the re-instatement of the receivable and how it now shows relative to the aging process |
| 19) Demonstrate how a user of your system would be able to modify AR invoices |
| a. Demonstrate how a user would place a invoice on hold and what the process would be to release the invoice from hold |
| b. Demonstrate the transaction of canceling or adjusting an invoice |
| 20) Demonstrate or explain your system's interface capabilities with other Systems | ||
| a. Demonstrate that they can receive files from subsidiary systems | ||
| b. Demonstrate ability to export and interface data to a ERP system | ||
| c. Capability to export and update payment information and AR balances back to subsidiary systems | ||
| Phase 2 Total | ||
| (Maximum 50 Points) | 0 |
List Source
| 0 |
| 1 |
| 3 |
| 4 |
| 5 |
image1.tmp image2.tmp image3.tmp image4.tmp image5.tmp image6.tmp image7.tmp image8.tmp image9.tmp image10.tmp image11.tmp image12.tmp image13.tmp
File details come from the government source that posted it. Updated .