What is Xstore?

Oracle Retail Xstore Point-of-Service is the software that runs on the actual cash registers (POS terminals) in the store. It is the final endpoint of the entire retail supply chain — the moment where merchandise that was planned, sourced, ordered, shipped, received, and priced finally meets the customer and generates revenue.

Xstore handles an enormous range of operations at the register:

Unlike web-based retail applications, Xstore is a thick-client Java application — it runs directly on the hardware in the store, not in a browser. This fundamental architectural decision drives everything else about the system: its offline capabilities, its performance characteristics, and its deployment complexity.

The Thick-Client Architecture

To understand Xstore, you must understand why Oracle chose a thick-client architecture instead of a thin-client (browser-based) approach.

A web-based POS would require a constant, reliable internet connection to a central server. In the real world, retail stores face:

• Network outages from ISP failures, construction accidents cutting fiber lines, or severe weather
• Latency spikes during peak hours (Black Friday, holiday seasons)
• Bandwidth constraints in rural or international store locations

If a web-based POS loses its connection, the store cannot sell. For a retailer with 3,000 stores doing $50,000/day per store, even one hour of downtime across the chain costs $6.25 million in lost revenue.

Xstore solves this by running the entire application locally on the register hardware. The architecture follows a three-tier model:

Offline Resilience

The most critical architectural requirement of a POS system is Offline Resilience. If a store's internet connection goes down, the store must still be able to sell products.

Xstore is designed with a complete data autonomy model. Each register has a local database containing everything it needs to operate independently:

1. Item Master — A complete copy of every item that this store is authorized to sell, including UPC barcodes, descriptions, and item hierarchy information
2. Pricing Rules — All active price changes, promotions, and markdown rules applicable to this store's zone
3. Tax Rules — Tax rates for the store's jurisdiction, including complex scenarios like tax holidays and exempt categories
4. Customer Data — Loyalty account information for customers who shop at this store
5. Employee Data — Cashier credentials, security roles, and manager override permissions

When the network drops, Xstore continues to:

• Ring transactions against its local database
• Calculate taxes using locally cached rules
• Apply promotions using locally cached promotion definitions
• Cache Transaction Logs (TLOGs) locally until the network is restored
• Queue customer loyalty point accruals for later synchronization

The Local Database (Apache Derby)

Each Xstore register runs an embedded Apache Derby database (previously JavaDB). Derby is a lightweight, zero-administration, Java-based relational database that runs in the same JVM process as Xstore itself.

The local database contains a subset of the enterprise data, tailored for this specific store. Key tables include:

Database Sizing

A typical Xstore local database is remarkably small — usually 200MB to 2GB — because it only contains data relevant to the single store. Compare this to the enterprise RMS database which can be 500GB+. This is why Derby works: the dataset fits comfortably in memory, enabling sub-millisecond query performance for item lookups during scanning.

TLOG Structure & Transaction Flow

When a cashier completes a transaction, Xstore generates a Transaction Log (TLOG). The TLOG is the canonical record of everything that happened at the register and is the primary data artifact that flows upstream to headquarters.

The TLOG Lifecycle

┌──────────────┐     ┌──────────────┐     ┌──────────────┐     ┌──────────────┐
│   Customer   │────▶│   Register   │────▶│  Store Server │────▶│   Xcenter    │
│  Scans Items │     │  (Xstore)    │     │  (Xstore     │     │  (Corporate) │
│              │     │  Creates     │     │   Office)    │     │              │
│              │     │  TLOG        │     │  Aggregates  │     │  Routes to   │
│              │     │              │     │  TLOGs       │     │  ReSA / RMS  │
└──────────────┘     └──────────────┘     └──────────────┘     └──────────────┘

TLOG Data Elements

A single TLOG contains extraordinary detail about the transaction:

• Header: Transaction number, store number, register number, cashier ID, start time, end time, transaction type (sale, return, void, no-sale)
• Line Items: For each item scanned: item ID, UPC, quantity, unit price, extended price, discount amount, discount reason, tax amount, serial numbers (if applicable)
• Tenders: For each payment method: tender type, amount, change due, authorization code, card last-4 digits (masked), approval status
• Tax Details: Tax jurisdiction, taxable amount, exempt amount, tax rate applied, tax amount calculated
• Customer: Loyalty card number, customer name, points earned, points redeemed
• Discounts: Promotion ID, discount type (percentage, amount, BOGO), discount amount, coupon number

Trickle Polling vs End-of-Day

Modern Xstore implementations use trickle polling — TLOGs are uploaded to the store server and then to Xcenter throughout the day, typically every 5–15 minutes. This replaced the legacy end-of-day batch approach and provides near-real-time visibility to headquarters.

<Transaction>
  <TransactionHeader>
    <StoreId>1042</StoreId>
    <RegisterId>003</RegisterId>
    <TransSeq>20260716-003-00142</TransSeq>
    <TransType>SALE</TransType>
    <BeginDatetime>2026-07-16T14:23:01</BeginDatetime>
    <EndDatetime>2026-07-16T14:25:33</EndDatetime>
    <CashierId>EMP-4521</CashierId>
  </TransactionHeader>
  <LineItems>
    <LineItem Seq="1">
      <ItemId>100400012345</ItemId>
      <Quantity>2</Quantity>
      <UnitPrice>29.99</UnitPrice>
      <ExtendedAmt>59.98</ExtendedAmt>
      <TaxAmt>4.80</TaxAmt>
    </LineItem>
  </LineItems>
  <Tenders>
    <Tender Seq="1">
      <TenderType>CREDIT</TenderType>
      <Amount>64.78</Amount>
      <AuthCode>A04521</AuthCode>
    </Tender>
  </Tenders>
</Transaction>

Payment Integration

Xstore integrates with payment terminals (also called Electronic Funds Transfer or EFT devices) through a configurable payment middleware layer. The architecture supports multiple payment processors and terminal hardware vendors.

Payment Flow

1. Cashier presses Total — Xstore calculates the transaction total including taxes and discounts
2. Customer presents payment — The cashier selects the tender type (credit, debit, cash, gift card)
3. EFT Device activation — Xstore sends the amount to the PIN pad / card reader
4. Card capture — Customer inserts chip, taps contactless, or swipes. The terminal encrypts the card data
5. Authorization request — Xstore sends the encrypted payment data to the payment processor (via the store's internet connection)
6. Authorization response — The processor approves or declines. Xstore records the auth code
7. Receipt generation — Xstore prints the customer receipt and the merchant copy

Offline Payment Authorization

When the internet is down, credit card authorizations cannot reach the processor. Retailers configure floor limits — a maximum transaction amount that can be authorized offline. Transactions below the floor limit are approved locally and queued for batch authorization when connectivity is restored. Transactions above the floor limit can only be completed with cash or stored-value tenders.

Xcenter & Corporate Sync

While the registers operate independently, headquarters needs to manage them centrally. This is where Xcenter comes in. Xcenter is the corporate-level server for Xstore and serves as the bridge between the stores and the enterprise back-office systems.

Data Flowing Down (HQ → Stores)

RMS and RPCS push updates to Xcenter, which then broadcasts them to every store:

• New Items: When a buyer creates a new item in RMS, RIB publishes a message. Xcenter receives it and pushes the item data to the local Derby database of every store that is authorized to sell that item.
• Price Changes: When a price analyst creates a regular price change in RPM/RPCS, the new retail is published via RIB to Xcenter, which distributes it to affected stores for the effective date.
• Promotions: New BOGO deals, percentage-off offers, and coupon definitions are deployed from RPM to Xcenter to stores.
• Employee Updates: New hires, terminations, and role changes flow from the HR system to Xcenter to the local register databases.

Data Flowing Up (Stores → HQ)

As registers ring transactions, they send their TLOGs up through the chain:

• TLOGs → Xcenter → ReSA: Transaction logs are sent to Xcenter, which routes them to Oracle Retail Sales Audit (ReSA) for financial auditing, balancing, and fraud detection.
• TLOGs → Xcenter → RMS: After ReSA validates the transactions, the sales data flows to RMS, which uses it to reduce ITEM_LOC_SOH.STOCK_ON_HAND and post financial entries to the STOCK_LEDGER.
• Inventory Updates: If a store performs a stock count or receives a shipment via SIOCS, that inventory data flows through Xcenter to update RMS.

Xstore Office & Back Office

Xstore Office is the store-level management application that runs on the store server (or lead register). It provides store managers with tools that go beyond basic register operations:

• End-of-Day Processing: Closing registers, balancing tills, generating daily sales reports
• Employee Management: Creating cashier accounts, assigning roles, managing schedules
• Reporting: Store-level sales reports, hourly transaction volumes, top-selling items
• Till Management: Opening/closing tills, performing till counts, managing safe drops and pickups
• Configuration: Store-specific settings like receipt headers, tax overrides, and floor limits

Xstore Office also serves as the data aggregation point — it collects TLOGs from all registers in the store and handles the upstream communication to Xcenter.

Deployment Topology

A typical Xstore deployment for a large retailer looks like this:

                    ┌─────────────────────┐
                    │     XCENTER          │
                    │  (Corporate HQ)     │
                    │  - Central database  │
                    │  - Data distribution │
                    │  - TLOG collection   │
                    └──────────┬──────────┘
                               │
              ┌────────────────┼────────────────┐
              │                │                │
     ┌────────▼──────┐ ┌──────▼────────┐ ┌─────▼───────┐
     │  Store 1042   │ │  Store 2105   │ │  Store 3201 │
     │  (Xstore     │ │  (Xstore     │ │  (Xstore   │
     │   Office)    │ │   Office)    │ │   Office)  │
     └───────┬──────┘ └──────┬───────┘ └─────┬──────┘
             │                │               │
      ┌──────┼──────┐   ┌────┼────┐     ┌────┼────┐
      │      │      │   │    │    │     │    │    │
    REG1   REG2   REG3 REG1 REG2 REG3  REG1 REG2 REG3

Each register is a self-contained unit running:

• Java Runtime Environment (JRE)
• Xstore POS Application (Java)
• Apache Derby Database
• EFT/Payment Middleware
• Peripheral Drivers (receipt printer, barcode scanner, cash drawer, PIN pad)

Configuration & Customization

Xstore is highly configurable through its configuration framework. Rather than modifying source code, retailers customize behavior through configuration parameters stored in the local database.

Key Configuration Areas

• Receipt Templates: Customizable receipt layouts including headers, footers, promotional messages, and barcode formats
• Security Policies: Manager override thresholds, void limits, return policies, and cashier permissions
• Tax Configuration: Multi-jurisdictional tax rules, tax holidays, and exempt categories
• Promotion Engine: Rules for automatic discount application, coupon validation, and loyalty point calculations
• Peripheral Configuration: Printer models, scanner types, payment terminal protocols, and customer displays