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 ACE Reports with ELERA reports, and bring discrepancies to the surface while teams still have time to resolve them.
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 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
- Live preparation, injection progress, and downloadable results
Compare ACE and ELERA reports
Use the same production transaction population to automate comparison of ACE Reports with ELERA financial reports, classify expected differences, and direct attention to true defects.
- Store/day, terminal, operator, transaction, item, and quantity
- Subtotal, tax, discount, tender, void/refund, and total
- Exact, equivalent, expected, verify, or defect disposition
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.
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.






The Phase 3 goal
Turn report validation into a discrepancy worklist.
Today, teams can spend days aligning source transactions, ELERA activity, and financial reports by hand. The Onboarding roadmap uses the same captured store and production TLOG to automate that correlation, compare ACE Reports with ELERA reports, and isolate the differences that actually need investigation.
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.
Active testing · Beta customers wanted
Help prove the path with a real ACE store.
We are looking for ACE customers who want to test a representative production store, production TLOG, and financial report set. Beta participation will help validate source variants, item and restriction fidelity, operational scale, expected differences, and the report-comparison workflow before broader release.