Coming soon · Active testing · Beta testers needed
ACE production store → ELERA
Onboard the store. Replay its reality. Prove the result.
REDList ACE Onboarding turns a captured production ACE store into a guided ELERA onboarding plan. It maps supported store configuration, publishes versioned ELERA data through controlled workflows, and validates the result with a production ACE TLOG.
The goal is a faster, evidence-based transition: automate the repeatable work, compare each transaction across the TLOG and electronic journals, compare ACE reporting with ELERA reporting, and surface discrepancies while teams still have time to resolve them.
Actively TestingBeta Testers NeededProduction ACE SourcesProduction TLOG ReplayTLOG-to-ELERA Journal ChecksJournal + Report Reconciliation
The production TLOG advantage
Lift the store’s reality. Shift it into ELERA. Prove every result.
The best ACE-to-ELERA lift-and-shift starts with the production ACE TLOG. Configuration tells you what the store should do; the TLOG shows what it actually did—what it sold, counted, priced, discounted, taxed, tendered, voided, and totaled. REDList uses that real transaction evidence to recreate, replay, and reconcile the store in ELERA.
One guided validation path
Move the store, then test what moved.
Onboarding is designed as a progressive proof—not a one-time data dump. Each phase adds a stronger level of confidence, from configuration integrity to transaction behavior, transaction-level electronic-journal comparison, and ultimately financial-report reconciliation.
Capture and onboard the store
A read-only collector packages supported ACE master data into a checksummed bundle. The app analyzes it, shows every mapping and warning, then publishes the approved ELERA store in dependency order.
- Node, taxes, catalog groups, items, prices, restrictions, and operators
- Versioned catalog and price-list data with isolated staging
- Count and deterministic item/price read-back before cutover
Validate and inject the production TLOG
The completed onboarding is paired with a production ACE TLOG. Onboard classifies SKUs, operators, and terminals, provisions persistent virtual terminals, and sends eligible baskets through REDList VTERM.
- Replayable, added, verify, and blocked SKU classifications
- Exact ACE terminal and operator attribution where supported
- TLOG-to-ELERA journal spot-checks across items, coupons, taxes, tenders, and totals
- Live preparation, injection progress, and downloadable results
Validate the replayed store
Three independent checks compare what ELERA did with what ACE recorded for the same production transactions. The overall verdict is the worst of them, and a check that has not run counts as neither a pass nor a failure.
- Transaction Reconciliation: ACE TLOG against each ELERA transaction
- Journal Comparison: ACE and ELERA printed receipts, line by line
- Report Comparison: ACE report totals against ELERA reporting
- Expected caveats separated from differences that require investigation
Production store coverage
Carry the configuration that makes a store behave like itself.
Onboard reads purpose-specific ACE sources rather than treating a store as a flat item export. That lets the migration retain relationships among departments, merchandise, pricing, tax, restrictions, operators, and the target ELERA node.
Catalog structure
ACE department descriptions become store catalog groups, giving each supported merchandise item a direct, traceable home.
Versioned selling data
Logical ACE item numbers, descriptions, base prices, quantities, tax flags, and audit attributes become aligned catalog and price-list records.
Store policy context
Tax plans and item tax flags are published together. Restricted Sale Type can become categories with customer/operator age and quantity-limit behavior.
Store-scoped identity
ACE operator intent maps to ELERA users and store roles, while the approved catalog, price list, and tax set attach at one guarded cutover point.
Item fidelity
Items are more than a SKU and a price.
Onboard handles the broad ordinary-item population while preserving the ACE fields needed to understand exceptions. The application makes confidence visible so a retailer can test what was mapped exactly and focus review where ACE and ELERA semantics differ.
Logical item identityRemoves ACE storage padding without guessing barcode aliases, while retaining the exact ACE value for audit.
Departments and base pricingCreates catalog-group ownership, aligned price records, and quantity bases for supported ordinary pricing methods.
Taxes and restricted salesMaps item tax flags plus age-to-buy, age-to-sell, grandfather date, and policy-wide quantity behavior when source policy data is available.
Scale and price-required itemsPublishes eligible weighted merchandise with LB units, flags it for verification, and corrects supported split-package/tare price overlays.
Linked-item analysisRetains and classifies source relationships so unsupported promotion semantics remain visible instead of being silently lost.
Enterprise volumeLoads large item and price populations in isolated transactional batches, validates saved counts, and checks representative records before cutover.
Deliberate boundary: hardware scale/barcode configuration, inferred UPC aliases, special item types, and linked-item promotion execution are not silently invented. They remain explicit verification or follow-up work for the beta and rollout process.
Screens from active testing
See the workflow make migration work visible.
These are current application screens from production-shaped testing. Select any screenshot to inspect the complete view.
Phase 3 · Data validation · Active testing
See how ELERA behaves with your real data before go-live.
Phase 1 onboards the production store and collects its data. Phase 2 replays that store’s real ACE TLOG into ELERA, with a review of exactly what will replay before anything is injected. Phase 3 then validates the replayed store, so the question “will ELERA do what ACE did?” is answered with the store’s own transactions rather than a demo script.
1 · Transaction ReconciliationMatches every ACE TLOG transaction to its ELERA counterpart and compares totals, items, tenders, operators, and prices. Both sides are structured and keyed by item code, so this is the exact, to-the-cent check.
2 · Journal ComparisonSets the ACE and ELERA printed receipts side by side, line by line. Lines that pair but differ, lines only ACE printed, and lines only ELERA printed are flagged, and each transaction gets Pass, Pass with caveats, or Fail with the share of lines that agree.
3 · Report ComparisonCompares ACE report totals with ELERA’s reporting for the same activity. It depends on which ACE reports a store runs and captures, so it is the most store-specific of the three.
Caveats versus issues: not every difference is a defect. ELERA prints SUBTOTAL and item-count lines that an ACE journal may not, prices from its published price list rather than the historical TLOG, and may map a tender differently. Those are shown as explained caveats. Missing or extra items, totals that do not recompute, taxability differences, and unexplained tenders stay visible as findings to fix before cutover.
The result is evidence-based cutover confidence: a retailer can review, transaction by transaction, how ELERA handled a full store day of production activity, and decide what still needs attention before go-live.
Validation screens from active testing
Every difference, side by side.
Current screens from testing against a full store day of production transactions. Results reflect work in progress, including findings still being resolved.
Guardrails for production-shaped work
Automation with visible boundaries.
Moving a store and replaying its activity requires more than speed. Onboard binds approval to the analyzed source, checkpoints completed stages, and stops when ELERA integrity checks do not match.
Read-only ACE capture
The collector reads source files, verifies copies, and creates checksummed evidence without modifying the ACE store.
Review before publish
Mappings, warnings, counts, and immutable fingerprints are presented before any approved ELERA publication begins.
Staged and recoverable
Versioned catalog and price data load behind isolated scope; checkpoints support safe resume and prior node selections remain restorable during validation.
Strict validation failures
Import rejection, count mismatch, or exact item/price read-back mismatch stops before cutover and cannot be waved through.
Beta testing
We need beta testers to complete real-data validation.
Lab data can only take the testing so far. REDList is looking for ACE retailers willing to work with us using representative data from one production store: store configuration, a production TLOG, the matching ACE Electronic Journal, and related financial reports. That data will help us finish testing source variations, transaction comparisons, expected differences, operational scale, and report reconciliation before broader release.
Interested? Start with a conversation. We will review scope and data handling with your team before anything is transferred. Please do not attach production data to the initial email.
One representative ACE production store
Production TLOG and matching Electronic Journals
Related ACE financial reports
Operations and accounting feedback