ADDENDUM #1: RFP55-100226-POINT OF SALE SYSTEM AND ERP BOLT-ON

FUNCTIONALITY FOR THE APPALACHIAN STATE UNIVERSITY CAMPUS STORE-

Questions & Answers & Attachments Included

STATE OF NORTH CAROLINA

Appalachian State University

Refer ALL Inquiries regarding this

RFP to:

Lori Brown Email: brownlg2@appstate.edu

PH: 828-262-8130

Request For Proposal # RFP55-100226

Bids will be publicly opened: Oct. 30, 2026 @ 2:00 pm

Contract Type: Open Market

Commodity Description: POINT OF SALE SYSTEM AND ERP BOLT-ON

FUNCTIONALITY FOR THE APPALACHIAN STATE UNIVERSITY CAMPUS

STORE

Using Agency: Appalachian State University

This addendum is issued to:

RFP55-100226_ POINT OF SALE SYSTEM AND ERP BOLT-ON FUNCTIONALITY FOR THE APPALACHIAN STATE

UNIVERSITY CAMPUS STORE – QUESTIONS & ANSWERS:

Following the review of all submitted bids, Appalachian State University will reach out to selected vendors once the finalist list has been determined. Finalists and the Department will then be given the opportunity to ask additional clarifying or detailed questions.

Questions and Answers:

RFP Section / page # Vendor Question/Response Response

Sections 4.1(H) and

5.2.3 Item 4 and

Attachment A, Estimated Third-Party Integration Fees, Pages 12, 19, and 31 Resero

For campus-card and payment integration fees, should bidders include all applicable fees charged by the University’s current provider, Watchman Payment Systems, or include only the bidder’s own implementation and recurring fees? If Watchman fees must be included, should bidders obtain new project pricing from Watchman or use pricing associated with the University’s existing agreement?

Bidders should quote the fees charged by the Vendor's own proposed solution (software, implementation, transaction/gateway, and recurring fees) and should not attempt to independently re-price the University's existing Watchman Payment Systems agreement. If the proposed solution requires new or modified work on the Watchman side, describe that scope and note it as a separate line; the University will coordinate any incremental Watchman project pricing directly with Watchman rather than through the bidder.

However, if any alternative 3rd party campus-card payment solution is recommended or required, bidders should include pricing for that solution.

mailto:brownlg2@appstate.edu

No Section Referenced Could you clarify whether the RFP permits an operational project-management prime with a named POS/eCommerce and ERP integration subcontractor, or whether the prime itself must hold the software licenses, certifications, and directly relevant deployment references?

If subcontracting is allowed, can the specialist's experience satisfy applicable past-performance criteria, and are there prime-level registration, insurance, or financial qualifications we should assess first?

An operational project-management prime partnering with a named POS/eCommerce and ERP integration subcontractor is permissible, consistent with RFP Section 4.13 (Subcontractors). The prime contractor remains fully responsible for contract performance, and the RFP does not require the prime itself to hold the underlying software licenses or certifications, but the proposal must clearly identify which entity (prime or subcontractor) holds each required credential, license, and certification, and the specialist subcontractor's relevant experience may be used to satisfy past-performance/reference criteria so long as its role in the proposed solution is clearly described. The prime must still meet the Section 4.3 (Financial Stability) and Secretary of State registration requirements (Section 4.14) in its own right;

subcontractor qualifications do not substitute for those prime-level requirements.

Sections 4.1(C), 4.10, and 5.2.3 Item 4, Pages 12, 15, and 19 Resero

Is continued use of FreedomPay mandatory, or may a bidder propose another payment gateway that uses Fiserv as the final merchant processor and satisfies the University’s requirements for PCI DSS compliance, P2PE, settlement, reconciliation, and the State’s merchant-processing agreement?

Continued use of FreedomPay is not mandatory.

However, a bidder may only propose another payment gateway that uses Fiserv as the final merchant processor and satisfies the University’s requirements for PCI DSS compliance, P2PE, settlement, reconciliation, and the State’s merchant-processing agreement.

12-RFP reference:

§5.2.3 item 4, p.19

Is FreedomPay required, or may respondents propose another Fiserv-approved gateway and certified PCI/P2PE hardware?

For campus cards, is full two-way authorization, balance check, debit, refund and reconciliation required, or is an externally processed tender recorded at POS acceptable?

Continued use of FreedomPay is not mandatory.

However, a bidder may only propose another payment gateway that uses Fiserv as the final merchant processor and satisfies the University’s requirements for PCI DSS compliance, P2PE, settlement, reconciliation, and the State’s merchant-processing agreement. For campus cards, full two-way authorization, balance check, debit, refund and reconciliation are required.

No Section Referenced How many current NetSuite users would require seats in a new software system?

Currently, there are 33 administrative users in NetSuite but we have licenses for 50.

No Section Referenced Please clarify the exact number of active POS devices/registers currently in scope for this project?

Current POS is owned; not leased.

The University would like to replace the following hardware, but Bidders should also indicate if any of this current hardware can be used as a backup.

Specifically, we are looking for the breakdown of fixed registers and mobile units deployed at the Main Campus Store (Boone) and the Hickory, NC location, as well as the typical number of devices required for peak seasonal pop-up events.

3 - UPC label printers 15 - Surface Pro 7 (10 fixed and 5 deployable for pop up events) 15 - Epson OmniLink TM-T88VI Receipt Printers 15 - Zebra LS2208 scanners 15 - APG cash drawers 15 - *FreedomPay card terminals (Ingenico Lane 7000)

*FreedomPay card terminals are purchased directly from FreedomPay through our campus gateway. You can add these to your proposal with a $0 bidding cost

RFP Section, Page Number Section 2. Pg 29/30

To provide a better generalized subscription cost, how many current seats do you have in Oracle, and how many POS terminals do you have?

Currently, there are 33 administrative users in NetSuite but we have licenses for 50.

Current POS is owned; not leased.

The University would like to replace the following hardware, but Bidders should also indicate if any of this current hardware can be used as a backup.

3 - UPC label printers 15 - Surface Pro 7 (10 fixed and 5 deployable for pop up events) 15 - Epson OmniLink TM-T88VI Receipt Printers 15 - Zebra LS2208 scanners 15 - APG cash drawers 15 - *FreedomPay card terminals (Ingenico Lane 7000)

*FreedomPay card terminals are purchased directly from FreedomPay through our campus gateway. You can add these to your proposal with a $0 bidding cost

Sections 4.1(D), 5.2.1 Item 12, and 5.3 Task 5, Pages 12, 18, and Resero

How many payment terminals or card readers does the Campus Store currently use at each location? How many terminals does the University anticipate deploying with the new solution at each permanent, mobile, event, or seasonal location?

Current POS is owned; not leased.

The University would like to replace the following hardware, but Bidders should also indicate if any of this current hardware can be used as a backup.

3 - UPC label printers 15 - Surface Pro 7 (10 fixed and 5 deployable for pop up events) 15 - Epson OmniLink TM-T88VI Receipt Printers 15 - Zebra LS2208 scanners 15 - APG cash drawers 15 - *FreedomPay card terminals (Ingenico Lane 7000)

*FreedomPay card terminals are purchased directly from FreedomPay through our campus gateway. You can add these to your proposal with a $0 bidding cost

Sections 5.2.1 Items 7 and 12 and 5.2.3 Item 4, Pages 18–19 Resero

Please identify the manufacturer and model of each payment device currently in use, the quantity of each model, and the devices on which the FreedomPay gateway or application is currently deployed.

Please also identify whether the current devices are owned, leased, or provided through the University’s Fiserv agreement.

Current POS is owned; not leased.

The University would like to replace the following hardware, but Bidders should also indicate if any of this current hardware can be used as a backup.

3 - UPC label printers 15 - Surface Pro 7 (10 fixed and 5 deployable for pop up events) 15 - Epson OmniLink TM-T88VI Receipt Printers 15 - Zebra LS2208 scanners 15 - APG cash drawers 15 - *FreedomPay card terminals (Ingenico Lane 7000)

*FreedomPay card terminals are purchased directly from FreedomPay through our campus gateway. You can add these to your proposal with a $0 bidding cost

Section 4.1(D) and Attachment A, Hardware Costs, Pages 12 and 30 Resero

If the University may acquire payment terminals through its existing Fiserv agreement, NC contract 500200-000, should bidders omit card-reader costs from the hardware pricing table, list the devices as University-provided with a $0 bidder cost, or provide separate bidder-supplied pricing as an alternative?

Current POS is owned; not leased.

The University would like to replace the following hardware, but Bidders should also indicate if any of this current hardware can be used as a backup.

3 - UPC label printers 15 - Surface Pro 7 (10 fixed and 5 deployable for pop up events) 15 - Epson OmniLink TM-T88VI Receipt Printers 15 - Zebra LS2208 scanners 15 - APG cash drawers 15 - *FreedomPay card terminals (Ingenico Lane 7000)

*FreedomPay card terminals are purchased directly from FreedomPay through our campus gateway. You can add these to your proposal with a $0 bidding cost

Sections 5.2.1 Items 7 and 15, 5.2.2 Item 7, and 5.2.3 Item 4, Pages 18–19 Resero

Please identify the payment channels and transaction types that the proposed gateway must support, including attended in-store payments, mobile or event payments, eCommerce payments, card-present refunds, card-not-present refunds, voids, reversals, split-tender transactions, and any stored-

Payment channels and transaction types that the proposed gateway must support include attended in-store payments, mobile or event payments, eCommerce payments, card-present refunds, card-not-present refunds, voids, reversals, split-tender transactions, $0 transactions (for our book rental program), $0 returns (for our book rental program), campus card/ID store value transactions.

payment or card-on-file use cases.

Section 4.1(C) and Attachment A, Payment Processing/Transaction Fees, Pages 12 and 30 Resero

Should bidders include the University’s existing Fiserv merchant-processing rates, FreedomPay gateway fees, device fees, PCI or security fees, and other charges under current University agreements, or should bidders report only payment-related fees introduced by the proposed solution? If existing rates must be included, will the University provide the applicable fee schedules?

Bidders should not include applicable fees charged by the University’s current card payment provider, FreedomPay. However, if any alternative 3rd party credit card payment solution is recommended, bidders should include pricing for that solution.

Continued use of FreedomPay is not mandatory.

However, a bidder may only propose another payment gateway that uses Fiserv as the final merchant processor and satisfies the University’s requirements for PCI DSS compliance, P2PE, settlement, reconciliation, and the State’s merchant-processing agreement.

Sections 5.2.1 Item 14 and 5.2.3 Item 3, Pages 18–19 Resero

For a Part 2 proposal, please identify the authoritative system for items, pricing, inventory, customers, gift cards, purchase orders, receiving, sales transactions, returns, and financial records. For each data category that must be exchanged with NetSuite, please identify the required direction of exchange and whether the near-real-time requirement applies.

The authoritative system for items, pricing, inventory, customers, gift cards, purchase orders, receiving, and sales and return transactions is NetSuite ERP currently. The authoritative system for financial records is Banner Finance. Near real-time data exchange is preferred.

ERP to POS exchange includes items, pricing, customers, inventory, gift card balances. POS to ERP exchange includes sales, return transactions, and gift card balance.

Primary data flows are as follows.

Banner to Verba Connect: enrollment file (student schedule data) Banner to Verba Collect: course adoptions (materials and course information) Banner to NetSuite ERP: customer and enrollment data Verba Collect to NetSuite ERP: course adoptions (generally includes editions, ISBN, title, author, publisher, publication date, cost and retail pricing, etc.)

NetSuite ERP to Verba Connect (through Compete): adoption export for student availability NetSuite ERP to AND from Solution POS/e- Commerce: to allow for purchase/rental at POS and eCommerce; to track transactions, gift card balances, and inventory depletion.

Sections 4.10, 5.2.3 Item 3, and 5.3 Task 4, Pages 15, 19, and 21 Resero

For Part 2 integration planning, will the University provide its NetSuite edition, enabled integration methods, relevant modules, available sandbox

The University currently operates NetSuite SuiteCommerce Advanced (SCA) running on version 2026.2.

Bidders should ensure that all proposed environment, expected transaction and item volumes, and any existing APIs, SuiteTalk services, integration records, file exchanges, or middleware that the selected vendor will be expected to use?

integration methods, APIs, and POS/Gateway connectors are forward-compatible with NetSuite's upgrade path, including planned transitions toward future core releases (including

2028.2 and later future releases NetSuite Next/SuiteSuccess frameworks).

A dedicated NetSuite SCA Sandbox environment will be made available to shortlisted vendor(s) during the Part 2 technical evaluation/proof-of-concept phase under standard security agreements.

Bidders should size system architecture and API throughput according to the following operational tiers:

Standard Baseline: Approximately 500 to 600 transactions/orders daily Fall Rush / Move-In Peak: Approximately 1,200 to 1,500 daily transactions during high-volume campus windows Outlier Event Stress Peak: Capacity to handle up to 2,000 daily transactions and rapid concurrent register bursts

Product Catalog: Approximately 30,000 active catalog SKUs/items managed across physical store and online channels.

Supported NetSuite Interfaces: Connectivity to SuiteCommerce Advanced may be achieved via native SuiteTalk (REST/SOAP Web Services), RESTlets, or automated SFTP file exchanges

(CSV/JSON/XML).

Middleware & Extensions: Vendors should specify whether their solution interacts directly with NetSuite via APIs/SuiteScripts or requires intermediate integration platform/middleware tools.

Detailed SuiteCommerce Advanced schema extensions, custom record definitions, custom field mappings, and sample API payloads will be provided to shortlisted vendors entering Part 2.

Sections 4.10 and

5.2.3 Item 6, Pages 15

and 19 Resero

For Part 1 proposals, will the University provide the current NetSuite-to-Banner Finance bill-export file layout, posting frequency, validation rules, chart-of-accounts mapping requirements, and sample files?

Please also identify whether

Bidders should describe their general approach and flexibility for building a comparable file-based or API interface to Banner Finance for AP and GL posting; a single combined interface or separate AP/GL interfaces are both acceptable, so long as data reconciles to the chart of accounts.

For Part 1 proposals, vendors should outline their standard integration architecture, capabilities, separate interfaces are required for accounts payable and general-ledger posting.

and previous experience integrating NetSuite or payment/POS solutions with Ellucian Banner Finance (including real-time API/Ethos integration

vs. scheduled flat-file/SFTP batch workflows).

Posting Frequency: Currently, billing and batch postings occur on a Daily basis. Bidders should specify if their proposed solution supports both real-time web service/API posting and scheduled automated batch (SFTP) processing. General Ledger (GL) Posting: Required for standard revenue recognition, cashiering batch settlements, payment processing fees, and daily tender reconciliation against Banner GL accounts. Accounts Payable (AP) Posting:

[Required Handled via Journal Voucher] to process vendor payouts, customer/student refund disbursements, and interdepartmental charge transfers. Bidders should indicate how their solution handles separate posting channels for GL journal entries versus AP invoice/credit generation.

Sections 1.1, 5.2.5 Item 6, 5.3, and 6.7, Pages 5, 20–21, and Resero

Does the University have a required production go-live date or latest acceptable cutover date associated with the NSPOS sunset? If so, please identify any blackout periods, academic-calendar constraints, inventory periods, or peak retail periods that must be considered in the implementation schedule.

Oracle has indicated NSPOS (NetSuite Point of Sale) is being sunset in 2029, which is the driver for this RFP; the University does not have a single fixed contractual go-live deadline tied to that date but intends to transition ahead contract renewal in December 2027. A specific target production go-live date has not been finalized;

internally. An ideal go-live for testing and possibly running systems side-by-side would be April - June 2027.

Section 4.6, Page 14 Resero

For the requirement to provide three references using the “exact model of services offered,” will the University accept references that collectively demonstrate the proposed retail platform, accounting integration, payment-system integration, and comparable ERP connectivity, or must each reference use the complete proposed combination of products and partners?

For the requirement to provide three references using the “exact model of services offered,” the University will accept references that collectively demonstrate the proposed retail platform, accounting integration, payment-system integration, and comparable ERP connectivity.

Reference must speak to how well the platform/connectivity integrates across other systems they are using.

Section 2.8(m), Page 8 Resero

If a bidder does not maintain a SOC 2 Type II report issued specifically for the bidder, will the University accept relevant hosting-provider and named-platform-partner SOC 2 Type II

Yes. Where a bidder does not maintain its own SOC 2 Type II report, the University will accept the relevant hosting-provider and/or named platform-partner SOC 2 Type II report(s), together with the bidder's current HECVAT, PCI compliance documentation (e.g., AOC/SAQ), a reports together with the bidder’s current HECVAT, PCI documentation, independent security assessments, Data Processing Agreement, and other documented control evidence?

Data Processing Agreement, and any independent security assessment or VPAT documentation, as collectively satisfying Section 2.8(m). The proposal should clearly identify which entity each piece of evidence applies to and how that entity's control environment covers the bidder's proposed solution.

No Section Referenced Please provide the current and projected number of fixed and seasonal register lanes, payment terminals, administrative users, annual in-store transactions, annual eCommerce orders, and gross merchandise volume by location, and identify which existing Surface devices, scanners, label printers, and payment terminals the University expects to reuse.

Current POS is owned; not leased.

The University would like to replace the following hardware, but Bidders should also indicate if any of this current hardware can be used as a backup.

3 - UPC label printers 15 - Surface Pro 7 (10 fixed and 5 deployable for pop up events) 15 - Epson OmniLink TM-T88VI Receipt Printers 15 - Zebra LS2208 scanners 15 - APG cash drawers 15 - *FreedomPay card terminals (Ingenico Lane 7000)

*FreedomPay card terminals are purchased directly from FreedomPay through our campus gateway. You can add these to your proposal with a $0 bidding cost

No Section Referenced For Banner, VitalSource, NetSuite, Watchman, Transact, FreedomPay/Fiserv, and UPS, please identify the current interface method, data owner, available technical documentation, test or sandbox environment, expected transaction frequency, and any third-party licensing or certification fees the Vendor must include.

Banner (Student Information System, owned by the University's ITS/Registrar's office) currently feeds student/course/registration data on at least a nightly basis; VitalSource (Equitable Access digital rentals) integrates with the current SCA storefront and NetSuite; Watchman and Transact Mobile ID are the University's campus-card platforms; FreedomPay is the University's current Fiserv-approved payment gateway with its own merchant IDs per location; UPS is used for shipping label generation/rate calculation. The University will coordinate with each system owner to provide further technical documentation, sandbox/test access, and fee information to the vendor(s) selected for implementation.

No Section Referenced Please define the required migration scope for each award scenario, including years of transaction and financial history, item and customer volumes, open rentals, gift-card balances, inventory records, eCommerce accounts, and whether the University or Vendor will be

Bidders should plan for the following baseline migration requirements across award scenarios:

Transaction & Financial History:

Active/Live Data: All open orders, pending authorizations, active authorizations, and unsettled batch records must be migrated or reconciled at go-live.

responsible for source-data cleansing and extraction from NetSuite.

Historical Financials: In alignment with Appalachian State University and UNC System Records Retention Schedules, 3 years of detailed transaction logs (for PCI/merchant processing compliance) and 7 years of general accounting summaries/journal entries must be accessible for financial audit requirements. [3 years] of historical transaction logs and general ledger posting summaries must be migrated or archived into an accessible reporting/auditing repository to satisfy financial audit and PCI compliance requirements.

Detailed line-item historical re-processing is not required; summary audit history is preferred.

Master Data & Balances:

Customer & eCommerce Accounts: Migration of active customer profiles and accounts [e.g., ~78,000 active accounts]. Stored payment methods (Card-on-File) must be securely migrated via token exchange/gateway-to-gateway token migration scripts to preserve customer vaulted cards without exposing raw PAN data.

Gift Cards & Store Credits: 100% of unredeemed gift card balances, store credits, and liability records must be fully migrated with original card/voucher identifiers intact.

Open Rentals / Recurring Obligations: All active equipment, textbook, or facility rentals, along with active recurring billing profiles, must be migrated with associated payment tokens and scheduled execution dates.

Inventory & Catalog Records: Migration of active SKU/item catalog records [e.g., ~30,000 items] and initial opening inventory balance counts across physical POS and eCommerce locations.Roles & Responsibilities (Data Cleansing & Extraction)

University Responsibilities:

Source Extraction: The University will be responsible for extracting raw source data from NetSuite SuiteCommerce Advanced, Ellucian Banner, and legacy systems into agreed-upon standardized formats (CSV, JSON, or staging database).

Data Cleansing: The University will handle initial source-data cleansing, deduplication, and mapping validation prior to handing files over to the vendor.

Vendor Responsibilities:

Import & Transformation: The Vendor is responsible for providing data import templates, transformation specifications, loading data into the target environment, developing and executing validation scripts.

Token Migration: The Vendor will coordinate directly with legacy payment processors/gateways to execute secure, PCI-compliant gateway-to-gateway token migration for stored credit cards.

Reconciliation & Validation: The Vendor must assist in dual-run data validation, record-count auditing, and balance reconciliation prior to final sign-off.

No Section Referenced What is the University’s required production go-live date, and are there academic-calendar, textbook-rush, fiscal-close, or retail blackout periods that constrain testing and cutover?

Please also confirm whether a phased deployment or temporary coexistence with the current platforms is acceptable.

Oracle has indicated NSPOS (NetSuite Point of Sale) is being sunset in 2029, which is the driver for this RFP; the University does not have a single fixed contractual go-live deadline tied to that date but intends to transition ahead contract renewal in December 2027. A specific target production go-live date has not been finalized;

internally. An ideal go-live for testing and possibly running systems side-by-side would be April - June 2027.

No Section Referenced Please provide the minimum UAT exit criteria, required production availability, severity-based response and resolution targets, disaster-recovery objectives, peak-period support coverage, and expected duration or location of go-live support that will be used for acceptance and ongoing performance management.

Before moving to production, the solution must satisfy all of the following exit criteria:

Functional Acceptance: 100% execution of agreed-upon UAT test scripts covering all payment channels (Fixed POS, Mobile/Line- Busting, eCommerce, and Kiosks), tender types (Credit/Debit, Digital Wallets, Cash, Campus Cards [Transact, Illumina], and Banner Department Charges), and transaction operations (sales, voids, refunds, split-tenders). All defects must have an agreed-upon remediation plan or work-around. Successful end-to-end transaction flow and reconciliation reporting validated with Ellucian Banner, Campus Card systems, and merchant acquiring banks. Formal written acceptance sign-off from the project sponsor and technical team.

Bidders should propose their standard UAT methodology and acceptance criteria, standard SLA commitments by severity level; the University will negotiate final, contract-specific

SLA and acceptance terms with the awarded vendor(s) consistent with Sections 6.6 (Acceptance of Work) and 6.7 (Faithful Performance).

1-RFP reference: §1.0;

§2.7, pp.5,7

If a vendor proposes both a Part 1 full solution (Acumatica ERP, POS and eCommerce) and a Part 2 solution retaining NetSuite, must these be submitted and priced independently? May alternative eCommerce platforms be proposed as separately priced alternates?

Alternative eCommerce platforms be proposed as separately priced alternates. Each part of the platform can be proposed as a separate price and add on.

2-RFP reference:

§4.10; §5.1, pp.15–16

Beyond the listed POS and eCommerce improvements, what are the University’s three highest priorities for replacing or retaining its current ERP? Which accounting, purchasing, inventory or reporting activities currently require the most manual effort?

Some of orur highest priorities for replacing or retaining our current NetSuite ERP include cost, reporting capabilities, excellent course materials management, and customer support. The functions that require the most manual work are as follows:

Financial Reconciliation: Manual matching of payment gateway settlement batches against bank deposits, merchant fees, and Banner General Ledger (GL) postings.

Interdepartmental/Departmental Billing: Manual entry, validation, or batch upload of internal account codes (FOAPAL/indexes) for interdepartmental sales and charges.

Inventory & Auxiliary Reporting: Consolidating sales and inventory data across disparate auxiliary systems into centralized financial reports.

Refund Processing & Exception Handling:

Processing unreferenced refunds, split-tender reversals, and student account adjustments across multiple systems.

3-RFP reference: §5.3, p.21

What is the target go-live date relative to the NSPOS sunset?

Must POS, eCommerce and ERP go live simultaneously, or is a phased transition permitted?

What semester-start, adoption, holiday and major-event blackout dates should the implementation avoid?

Oracle has indicated NSPOS (NetSuite Point of Sale) is being sunset in 2029, which is the driver for this RFP; the University does not have a single fixed contractual go-live deadline tied to that date but intends to transition ahead contract renewal in December 2027. A specific target production go-live date has not been finalized;

internally. An ideal go-live for testing and possibly running systems side-by-side would be April - June 2027.

4-RFP reference: §4.1, pp.12–13; §5.3, p.21

Please provide the number of locations and registers, active SKUs/variants, inventory sites, suppliers, customers, estimated

Currently, there are 33 administrative users in NetSuite but we have licenses for 50.

Current POS is owned; not leased.

The University would like to replace the following

ERP users, annual/monthly POS and eCommerce transactions, purchase orders, AP invoices, and peak hourly/daily transaction volumes, as well as anticipated growth, to support accurate sizing and pricing.

hardware, but Bidders should also indicate if any of this current hardware can be used as a backup.

3 - UPC label printers 15 - Surface Pro 7 (10 fixed and 5 deployable for pop up events) 15 - Epson OmniLink TM-T88VI Receipt Printers 15 - Zebra LS2208 scanners 15 - APG cash drawers 15 - *FreedomPay card terminals (Ingenico Lane 7000)

*FreedomPay card terminals are purchased directly from FreedomPay through our campus gateway. You can add these to your proposal with a $0 bidding cost.

Bidders should size system architecture and API throughput according to the following operational tiers:

Standard Baseline: Approximately 500 to 600 transactions/orders daily Fall Rush / Move-In Peak: Approximately 1,200 to 1,500 daily transactions during high-volume campus windows Outlier Event Stress Peak: Capacity to handle up to 2,000 daily transactions and rapid concurrent register bursts

Product Catalog: Approximately 30,000 active catalog SKUs/items managed across physical store and online channels.

Supported NetSuite Interfaces: Connectivity to SuiteCommerce Advanced may be achieved via native SuiteTalk (REST/SOAP Web Services), RESTlets, or automated SFTP file exchanges

(CSV/JSON/XML).

5-RFP reference: §5.3;

§6.6, pp.21,23

What availability will University personnel have for requirements workshops, data cleanup, migration approvals, training and UAT? Can the University provide representative integration test scenarios, reconciliation control totals, and ERP/POS/eCommerce acceptance criteria?

The University's Campus Store and NetSuite/ERP support staff will be availability for requirements workshops, data cleanup, migration validation, training, and UAT for this project;

exact staffing/availability commitments will be finalized with the awarded vendor during project kickoff. Representative integration test scenarios and reconciliation control totals are not yet developed but can be built collaboratively with the awarded vendor's implementation team during the requirements phase. Dedicated project manager, technical support staff, and Campus Store staff will be available for implementation

6-RFP reference:

§5.2.1 items 3–4, p.17

For a true $0.00 physical textbook rental, is the entire basket always $0, or can it contain paid merchandise, taxes, deposits or fees? Must a payment credential, authorization or signed agreement be captured when no charge is due?

For the $0.00 physical textbook rental, the entire basket may not always be $0. The rental items would be $0 and tax exempt, however, shipping charges, or other items can be added to the total basket.

Ideally, payment credentials and processing would not be required if the total transaction is $0.

7-RFP reference:

§5.2.1 items 3–4, p.17;

§4.10, p.15

Please describe the end-to-end rental lifecycle, including eligibility, individual-copy tracking, contracts/acknowledgment, due dates, extensions, returns at another location, buyback, outstanding items, damage/loss charges and collection. Which system owns rental records and rental-related accounting today, and which must own them after implementation?

-App State has an equitable access (EA) rental program where students pay a fixed-rate term rental fee. The Campus Store only provides print rental texts whenever there is no digital match in VitalSource. We own these print rental texts and when faculty submit adoptions for their course sections, the enrolled/rental eligible students in that course section, check them out from the Campus Store for that term.

-Our ERP system has student enrollment feeds that come from Banner 4x per day.

Enrolled/rental eligible students can either check them out for the term by placing an online order at our website and then the Campus Store fulfills that $0 transaction- OR we can also check out rental texts to enrolled/rental eligible students via

POS.

-Students attest (checkbox) online to agree to return their rental texts by the deadline, when placing online orders. At POS transactions, students sign the rental agreement during that POS transaction. The current ERP system contains these term rental records for each student transaction.

-After implementation, the ERP system should contain these term rental records for each student.

-All print rental texts are due back in the Campus Store by the deadline (the Tuesday after the term final exams are completed) for each term. We have an ERP system report for all unreturned term rentals and we manually bill each student via university student accounts for the used cost of the text. We do not have this billing record for each individual student in ERP- that is kept in a separate document with the accounting team.

-The Campus Store no longer does a buyback at the end of the term.

8-RFP reference:

§5.2.2 items 3–4, p.18;

§5.2.3 items 1–2, p.19

Which systems maintain ISBN/edition, instructor, course-section, required/recommended materials, course-to-item

All of that information is housed in NetSuite currently, but that information is generated elsewhere, and brought into NetSuite using different loads. For example, student data, class mappings, student eligibility and Equitable Access entitlements?

Must physical rentals and VitalSource digital materials be purchasable in one mixed basket, and what access/fulfillment occurs after checkout?

data and enrollment data is automatically imported from Banner at the university. Book adoptions (course to item mappings) for classes are handled through Verba Collect, and that information is imported into NetSuite. We can also create adoption records in NetSuite without imports, but imports make it easier. The information for the books themselves are created on a spreadsheet, and imported into NetSuite.

That book info generally includes editions, ISBN, title, author, publisher, publication date, cost and retail pricing, etc.

Addressing the second question - VitalSource eBooks are not purchased or rented in any way on our website or through NetSuite. That process is handled through a different system called Verba Connect. Physical books are designated as rental items OR purchase items; the rental items are rented by the customer, while the purchase items are purchased by the customer.

Either way, those items are added to the shopping cart and checked out, just like a normal ecomm transaction. Orders are fulfilled by our ecommerce manager.

9-RFP reference:

§5.2.3 items 1–2, p.19

Can the University provide the Banner feed/API/file specifications, frequency, data dictionary, matching identifiers and sample records, as well as VitalSource API/entitlement documentation and test-environment availability? Which data must persist in the ERP versus an integrated course-material or commerce application?

The University will provide the relevant technical specifications, sample records, and test/sandbox access to the vendor(s) selected for implementation. Student data, class data and enrollment data is automatically imported from Banner. Data flows are as follows.

Banner to Verba Connect: enrollment file (student schedule data) Banner to Verba Collect: course adoptions (materials and course information) Banner to NetSuite ERP: customer and enrollment data Verba Collect to NetSuite ERP: course adoptions (generally includes editions, ISBN, title, author, publisher, publication date, cost and retail pricing, etc.)

NetSuite ERP to Verba Connect (through Compete): adoption export for student availability

10-RFP reference:

§5.2.1 items 3–4, p.17

Could the University provide anonymized examples of a $0 rental receipt, rental checkout and return records, outstanding-rental reports, student eligibility checks and any required rental acknowledgment?

Example records for a $0 rental receipt, return record and rental eligibity are attached as a separate pdf.

11-RFP reference:

§5.2.1 item 7, p.18;

§5.2.3 item 4, p.19

Please identify mandatory card-present/online payment flows and technical interfaces for Fiserv, FreedomPay, Watchman and Transact Mobile ID. What certifications and payment hardware are required, and which tender types must support split tender, refunds and outages?

Continued use of FreedomPay is not mandatory.

However, a bidder may only propose another payment gateway that uses Fiserv as the final merchant processor and satisfies the University’s requirements for PCI DSS compliance, P2PE, settlement, reconciliation, and the State’s merchant-processing agreement.

While we do not have a mandatory campus-card payment flow, we are requiring a solution to allow for campus card usage. We currently use Watchman Payment Systems. However, if any alternative 3rd party campus-card payment solution is recommended or required, bidders should include pricing for that solution. We do not want a separate Transact register (or side-car device) for campus card transactions. We are looking for a payment flow and campus card tender built into the POS solution. Campus card transactions must support Transact Mobile ID.

Tender types include Credit/Debit, Gift Card, Digital Wallets, Cash, Campus Cards/Mobile ID [Transact, Illumina], and Department Charges.

13-RFP reference:

§5.2.1 item 6, p.18

Are current gift cards physical, digital or both? Please provide issuer, active card count, balances, file/export formats and migration restrictions. Must gift cards be accepted across both POS and eCommerce? Are bookstore gift cards, campus cards and bookstore credits separate programs, and which systems own their balances and liabilities?

Gift cards are both physical and digital.The University's current gift cards are managed within its NetSuite/SCA platform (not a separate third-party gift card processor), supporting both in-store and online acceptance; the RFP requirement (Section 5.2.1 Item 6) is specifically to retain the ability to import existing gift card balances into whatever new solution is selected, so active balance/count data will be extracted and provided to the awarded vendor during migration planning rather than published in this response. If proposing an ERP replacement, solution must include continued use of legacy gift cards. Campus cash/campus-card balances (Watchman/Transact) are a separate program from Campus Store gift cards and are owned/managed by the campus card office, not the Campus Store; gift cards and campus cash should be treated as distinct tender types that must both be supported, not consolidated into one program.

14-RFP reference:

§5.2.1 item 8, p.18;

§5.2.3 item 6, p.19

For departmental/auxiliary charges, what authorization, fund/account validation, tax treatment, budget check, purchase-order reference, All departmental charges require a fund and account number. We need the ability for those to be taxable or non-taxable transactions. We do not balance or budget check prior to a departmental charge. For computers/tech store equipment, we create an internal PO within NS invoicing and settlement/posting workflows are required?

ERP to associate to any departmental charges.

Similar to any other tender, we would need to be able to report on Departmental Changes for monthly reconcilliation and reporting would need to include associated fund and account number.

15- RFP reference:

§5.2.5 item 2, p.20

Can the University provide a sample UBIT report and its buyer-affiliation/category classification rules? Is affiliation captured at transaction time or inherited from a customer record, and must historical affiliation be fixed for audit purposes? How should shipping, returns, discounts and departmental sales appear?

The University will provide the relevant technical specifications for UBIT reporting and sample records to the vendor(s) selected for implementation. However, affiliation is captured at transaction time. Historical affiliation must be fixed for audit purposes. Departmental sales, returns, and discounts should appear per affiliation per category. Shipping and tax would show per transaction.

16-RFP reference:

§5.2.1 item 2, p.17

What offline POS capabilities are required, including maximum outage duration, approved offline tenders, item/price cache, rental processing, receipts, inventory reservation and conflict resolution after reconnection?

Bidders should outline any offline capabilities and limitations within the solution.

The University's priority offline-POS scenario is a planned outage — for example, taking a register to an off-site or pop-up event without reliable connectivity — where the register should be able to process transactions locally and automatically synchronize once reconnected. We are also prioritizing offline-POS transaction up to specified amounts in an unplanned outage. Tenders should be able to be restricted for off-line processing.

POS terminals must be capable of printing physical receipts or queuing digital receipts (email/SMS) to send automatically once connectivity is re-established. Rental returns and drop-offs must be queueable offline. Inventory counts must be decremented locally during offline mode to maintain accurate physical counts on-site. Upon network reconnection, the system should automatically update any offline activity.

17-RFP reference:

§5.2.1 item 5, p.18;

§5.2.2 item 2, p.18

What maximum number of stacked promotions must be supported, including automatic discounts, codes, BOGO, quantity tiers and student/employee prices? Are shared promotion definitions mandatory, or are separate POS/eCommerce rules acceptable if resulting prices match? Please identify precedence and exclusions.

The RFP does not set a fixed maximum number of stacked promotions; the requirement (Section

5.2.1 Item 5) is that the solution support multiple

automatically-applied discounts and/or coupon-based discounts in combination, tiered quantity discounts, and BOGO-style promotions, consistently across POS and eCommerce. The University's preference is for a single shared promotion engine/rule set used by both channels (to guarantee matching prices), but separate POS and eCommerce rule configurations are acceptable as an alternative so long as the bidder can demonstrate that resulting prices reconcile between channels. Shared promotion definitions across eCommerce and POS will be preferred.

18-RFP reference:

§5.2.1 items 12–13, p.18

Please provide a register-by-register inventory of Microsoft Surface Pro models/OS versions, scanners, cash drawers, receipt printers, Avery/Dennison-type label printers and payment devices. Which items must be reused, and can examples of required labels/barcodes be provided?

Current POS is owned; not leased.

The University would like to replace the following hardware, but Bidders should also indicate if any of this current hardware can be used as a backup.

3 - UPC label printers 15 - Surface Pro 7 (10 fixed and 5 deployable for pop up events) 15 - Epson OmniLink TM-T88VI Receipt Printers 15 - Zebra LS2208 scanners 15 - APG cash drawers 15 - *FreedomPay card terminals (Ingenico Lane 7000)

*FreedomPay card terminals are purchased directly from FreedomPay through our campus gateway. You can add these to your proposal with a $0 bidding cost.

19-RFP reference:

§5.2.1 item 14, p.18;

§5.2.2 item 2, p.18

Does the target of 15 minutes or less apply to inventory alone, or also price, promotions, customer, gift card, rental, order, return and financial data? What are the maximum allowable intervals, inventory reservation/oversell rules and failure-recovery expectations for each?

The authoritative system for items, pricing, inventory, customers, gift cards, purchase orders, receiving, and sales and return transactions is NetSuite ERP currently. The authoritative system for financial records is Banner Finance. Near real-time data exchange is preferred.

ERP to POS exchange includes items, pricing, customers, inventory, gift card balances. POS to ERP exchange includes sales, return transactions, and gift card balance.

20-RFP reference:

§5.2.2 item 5, p.19

Which identity provider and protocols (SAML, Shibboleth or other) should be used for students and staff? Which shopper actions require login, and may guest users purchase/rent course materials or only general merchandise?

Appalachian State University utilizes Shibboleth / SAML 2.0 as its enterprise Single Sign-On (SSO) identity provider. The four approved ITS solutions are: Shibboleth, Azure Oauth , Active Directory (LDS) , and Google Oauth .

The proposed solution (both eCommerce web portal and administrative interfaces) must natively support SSO for user login, session management, and role-based access controls.

21-RFP reference:

§5.2.2 item 7, p.19

Which fulfillment options are mandatory at launch: home delivery, shipping to campus, BOPIS, cross-location pickup, split fulfillment or drop ship?

Which shipping carrier accounts, UPS tools and label/rate applications are currently used?

At minimum, store pickup (BOPIS), split fulfillment and shipped (UPS-labeled) fulfillment are expected to be available at launch, consistent with Section 5.2.2 Item 7; The University's current shipping process uses UPS for label generation and rate calculation.

22-RFP reference:

§5.2.4 items 1–5, p.20

Please describe inventory categories and ownership/costing rules for general merchandise, variants, consignment, physical rental stock, digital items and non-inventory items. Which system must perform counts, transfers, adjustments, purchasing, reorder points and demand planning?

The Campus Store carries general merchandise (with size/color variants), physical rental stock, and non-inventory/digital items (VitalSource-fulfilled digital materials are not physically inventoried by the Campus Store). The ERP (currently NetSuite) should be the authoritative system for counts, transfers, adjustments, purchasing, reorder points, and demand planning natively.

23-RFP reference:

§5.2.4 items 3–5, p.20

Are moving-average, linear-regression and seasonal-average forecasting methods individually mandatory or illustrative? Should auto-replenishment create suggested orders for buyer approval or submit purchase orders automatically?

Moving-average, linear-regression and seasonal-average forecasting methods are illustrative.

Auto-replenishment should create suggested orders for buyer approval.

24-RFP reference:

§5.2.5 item 1, p.20

For comparable same-day-prior-year sales reporting, should dates align by calendar day, weekday, academic event or fiscal/retail calendar? How should returns, exchanges, changed store locations and sale-date versus ERP-posting-date timing be handled?

Same-day-prior-year comparisons should align by both calendar day and academic/retail calendar context where possible (e.g., comparing the first day of fall rush this year to the first day of fall rush last year, which may not be the same calendar date): day to day comparison AND date to date comparison if possible. A strict calendar-day-only comparison is a reasonable baseline, but the University's preference is for the ability to also compare against an academic-event-anchored date.

Returns/exchanges should net against the original sale in the period they occur (not restated into the original sale's period), and reporting should be based on the transaction/sale date rather than the ERP-posting date.

25-RFP reference:

§4.10; §5.2.3 item 6, pp.15,19

For the full ERP option, please specify which financial functions remain in Banner Finance and which belong to the Campus Store ERP. Which system owns vendor masters, AP approval/payment, AR, settlement reconciliation, purchasing and the authoritative general ledger?

For a Part 1 (Full Solution) proposal, Purchase Orders are created and Bills are worked in the ERP system, but all of the AP approval/payment, AR, settlement reconciliation, and the general ledger are in Banner Finance. Banner Finance is expected to remain the University's authoritative, overarching general ledger and the system of record for the University's consolidated financial statements; the Campus Store ERP component is expected to own day-to-day retail accounting

— vendor/AP management specific to Campus Store purchasing, AR specific to departmental/auxiliary billing, inventory valuation, and settlement reconciliation — and to export summarized transactions to Banner Finance for consolidated GL posting, consistent with the University's current NetSuite-to-Banner export model. The awarded vendor's ERP is not expected to replace Banner Finance as the University's institution-wide GL.

26-RFP reference:

§5.2.3 item 3, p.19

For the option retaining NetSuite, please describe the NetSuite edition, important custom scripts/records and workflows, Suite Talk/API access, saved searches/file feeds, and target interfaces…