Retail Pro connection validation blueprint

Which database is under your Retail Pro, and what could a future pilot validate?

Retail Pro is not one database. Depending on edition and version, it can use Oracle, Microsoft SQL Server, or MySQL.¹ The engine helps identify a possible validation route, but it does not mean StoreRounds supports that edition. No Retail Pro production adapter is available today.

What is the proposed Retail Pro pilot boundary?

No StoreRounds Retail Pro driver is available today. A future pilot agent would use an edition-specific schema map and named read-only database user, minimize approved daily totals locally, and send them outward over an encrypted connection. The controls below are acceptance criteria, not deployed behavior.

Why can't a cloud tool just read Retail Pro?

Because Retail Pro keeps your sales in a database on a computer you control, behind a database login, not in a vendor's cloud with an open connection port. That is true whether your edition is on Oracle, SQL Server, or MySQL. Even the newer, web-based Retail Pro Prism serves that data from a server on your own network. A cloud dashboard has no neutral way to reach a database it does not host, so the honest way to read it is a database user, scoped tight and read-only.

How does the connection work across several stores?

A possible pilot topology would place an approved edition-specific edge agent near the back-office database and allow outbound-only transport to StoreRounds. The diagram is a design target, not a deployed connection.

Two facts worth repeating, because they are the whole security story:

• A future pilot agent would have to read over the local network and send only reviewed, minimized fields.
• The connection to StoreRounds is started from inside your store, going out. Your firewall does not need a new inbound rule. There is no port for an outsider to knock on.

What would a future Retail Pro pilot have to validate?

Five stages. Each ends with a verify step, so you never move on wondering whether the last part worked. Stage 1 is the database login and is the only stage that touches SQL. Use the block that matches your engine. If your IT person handles the database, send them stage 1 and do the rest yourself.

-- 1. Create a server login with a strong password.
USE [master];
CREATE LOGIN [storerounds_ro] WITH PASSWORD = '<STRONG_PASSWORD>',
     CHECK_POLICY = ON;
GO

-- 2. Map it to a user inside your Retail Pro database.
USE [<RETAILPRO_DB>];
CREATE USER [storerounds_ro] FOR LOGIN [storerounds_ro];
GO

-- 3. FUTURE PILOT ONLY: grant SELECT on the tables a validated adapter would read.
GRANT SELECT ON OBJECT::dbo.<SALES_DOC_TABLE>  TO [storerounds_ro];
GRANT SELECT ON OBJECT::dbo.<SALES_LINE_TABLE> TO [storerounds_ro];
GRANT SELECT ON OBJECT::dbo.<TENDER_TABLE>     TO [storerounds_ro];
GRANT SELECT ON OBJECT::dbo.<STORE_TABLE>      TO [storerounds_ro];
GO

-- 4. Belt and suspenders: explicitly deny anything that changes data.
DENY INSERT, UPDATE, DELETE, EXECUTE, ALTER, CONTROL TO [storerounds_ro];
GO

-- 1. Create a read-only user. Restrict the host to the connector
--    machine where you can, for example 'storerounds_ro'@'10.0.0.20'.
CREATE USER 'storerounds_ro'@'%' IDENTIFIED BY '<STRONG_PASSWORD>';

-- 2. FUTURE PILOT ONLY: grant SELECT on the tables a validated adapter would read.
GRANT SELECT ON <RETAILPRO_DB>.<SALES_DOC_TABLE>  TO 'storerounds_ro'@'%';
GRANT SELECT ON <RETAILPRO_DB>.<SALES_LINE_TABLE> TO 'storerounds_ro'@'%';
GRANT SELECT ON <RETAILPRO_DB>.<TENDER_TABLE>     TO 'storerounds_ro'@'%';
GRANT SELECT ON <RETAILPRO_DB>.<STORE_TABLE>      TO 'storerounds_ro'@'%';

-- 3. Apply. This user has SELECT only; it was never granted a write.
FLUSH PRIVILEGES;

How would a Retail Pro pilot prove it read the right store and numbers?

A founder-assisted pilot would select one approved store and closed sales day, retrieve totals through the edition-specific driver, and compare them with the owner's trusted Retail Pro report. The driver must remain unsupported until those values match and the owner confirms the definitions.

To pass the read-back test

1. In StoreRounds, open the connection and choose Run read-back test. Pick the store and confirm the date it selected.
2. In Retail Pro, open that store's Z-out or Sales Summary report for the same date.
3. Compare gross sales, transaction count, and the cash and card split. They should match to the cent.
4. If a future pilot matches, the owner would confirm the reconciliation. Only then could the connection be marked verified and a first Morning Flash be scheduled.

What if something goes wrong?

The common failures and what fixes them. Open the one that matches what you see.

How must a future Retail Pro pilot prove revocation?

Access is yours to end at any time, with no notice and no call. You have two independent switches, and either one alone stops the flow of data. Use both to remove every trace.

Switch 1: turn off the connector

The future pilot would need a verified pause, unpair, and uninstall path that removes its working credential. No such customer control is live today.

Switch 2: drop the database user

Dropping the dedicated read-only database user is the source-side stop. A future pilot must prove that an attempted read then fails closed.

USE [<RETAILPRO_DB>];
DROP USER [storerounds_ro];
GO
USE [master];
DROP LOGIN [storerounds_ro];
GO

DROP USER 'storerounds_ro'@'%';
FLUSH PRIVILEGES;

Frequently asked questions

Status for every answer below: no production Retail Pro adapter is live. These answers are blueprint assumptions that require edition-specific proof.