Coming soon · Active testing

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.

Actively TestingProduction ACE SourcesProduction TLOG ReplayVTERM + Load TesterReport Reconciliation Roadmap
Phase 1Capture, map, publish, and verify store configuration
Phase 2Classify and replay a production ACE TLOG through VTERM
Phase 3Automated ACE-versus-ELERA financial report comparison
BetaProduction-shaped customer testing partners wanted

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.

Phase 1 · Active testing

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
Phase 2 · Active testing

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
Phase 3 · Next milestone

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.

Departments

Catalog structure

ACE department descriptions become store catalog groups, giving each supported merchandise item a direct, traceable home.

Items + prices

Versioned selling data

Logical ACE item numbers, descriptions, base prices, quantities, tax flags, and audit attributes become aligned catalog and price-list records.

Tax + restrictions

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.

Operators + node

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.

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.

1 · CaptureProduction ACE store files, TLOG, and report evidence
2 · RecreateVersioned ELERA store configuration and identities
3 · ReplayEligible production transactions through VTERM
4 · ReconcileACE and ELERA financial output with classified findings
Store and dayTerminal and operatorTransaction and itemQuantity and void/refundSubtotal and taxDiscountTenderTotalReceipt attributionExpected vs. defect

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.

A representative ACE production-store bundle
One or more production TLOG samples
Matching ACE financial reports
Operations and accounting review participation