Next-Generation Store Sales Platform

QShop

Your store. Your sales. One screen.

QShop is QBS retail and store-sales software. It combines barcode and catalog-based quick sale, store-scoped product management, held baskets, multiple payment methods, cash registers, fiscal/POS devices, sale completion and return/cancellation flows.

Request a demo → Dealers & partners
QShop
DETAILED OVERVIEW

QBS retail software with a store-sales flow isolated from restaurant operations

QShop brings barcode and catalog-based quick sale, payments, stock, cash-register, device and return workflows together in one retail sales experience.

The store-sales flow is isolated from restaurant operations; sale, payment, stock and cash movements are managed as one consistent transaction chain.

Quick Sale

Barcode, catalog, groups and store-scoped product selection.

Single Transaction

Sale, payment, stock and cash records committed together.

Multiple Payments

Loyalty, customer balance/open account and payment-method infrastructure.

Safe Returns

Cloud reversal is not committed until the device result is definite.

Idempotency

The same completion key does not create a second sale.

Offline Queue

GUID JSON, RESULT_UNKNOWN and CLOUD_SYNC_PENDING safety.

CAPABILITIES

Product, Catalog and Pricing

Catalog & Barcode

  • Barcode product lookup.
  • Selection through product groups and catalog.
  • Store/SHOP product scope.
  • Variant and warehouse context on sale lines.
  • Product and warehouse context carried to the sale screen.

Multi-level Pricing

  • Multiple purchase-price levels.
  • SALE_PRICE levels 1–5.
  • Currency per level.
  • VAT mode per level.
  • PRODUCT_PRICE_HISTORY for purchase and sale price-change history.

Sale Actions

  • Quantity changes.
  • Price actions.
  • Salesperson context.
  • INVOICE_REQUIRED.
  • INVOICE_TYPE_CODE.
  • Invoice information JSON context.
CAPABILITIES

Quick Sale, Hold and Completion

SHOP Isolation

  • SHOP flow does not read/write restaurant FOOD order tables.
  • Store sales live on SHOP_SALES / SHOP_SALE_LINES.
  • Payment, stock and cash movements complete in the same SQL transaction.

Held Sale

  • Held basket/sale flow.
  • Resume and complete sale context.
  • Store sales remain separate from FOOD orders.
  • Held store basket remains in the Cloud shop-sale flow.

Idempotency

  • IDEMPOTENCY_KEY on completion.
  • If the key already completed, return the existing SHOP_SALES record instead of creating another.
  • Return existing SALE_NO and PAYMENT_TRANSACTION_ID.
  • Designed to prevent duplicate stock/cash/payment movements.
CAPABILITIES

Payments and Customer Value

Payment Methods

  • Resolve payment method by ID.
  • Multiple payment lines per sale.
  • Paid total and change total.
  • QAD_PAYMENT_TRANSACTIONS records.
  • QAD_PAYMENT_TRANSACTION_LINES records.
  • Positive amount and valid-method validation.

Loyalty

  • Loyalty-account context.
  • Point-out / point-balance movement.
  • Monetary loyalty movement.
  • Sale and payment transaction references.
  • Reference number for audit trail.

Customer Balance / Open Account

  • CUSTOMER_BALANCE and OPEN_ACCOUNT payment types.
  • Customer is mandatory.
  • Active CUSTOMER_BALANCE_ACCOUNT required.
  • CURRENT_BALANCE update.
  • ALLOW_NEGATIVE_BALANCE permission.
  • CREDIT_LIMIT validation.
  • Block insufficient customer balance.
CAPABILITIES

Stock, Warehouse and Cash Movements

Warehouse Stock

  • PRODUCT_WAREHOUSE_STOCKS.
  • QAD_SHOP_STOCK_MOVEMENTS header.
  • QAD_SHOP_STOCK_MOVEMENT_LINES.
  • Stock movements are written in the same SQL transaction as the sale.
  • Warehouse/variant references are preserved on sale and return lines.

Cash

  • Sale linked to cash movement.
  • Original cash records are not deleted on cancel/return.
  • Reversal-record approach.
  • Sale, payment, stock and cash integrity share the same transaction boundary.
CAPABILITIES

Sale Query, Full Cancellation and Full/Partial Return

Device-first Flow

  • Sale/query/cancel/return are disabled until a device is selected.
  • Selected DEVICE_ADAPTER_CODE is resolved by the central dispatcher.
  • The frame does not call a vendor client directly.
  • Pavo, Beko, Hugin and other devices use a common adapter contract.
  • No unverified Beko/Hugin endpoint or method is invented.

Full Cancellation

  • Full cancellation may be blocked when another physical-device payment exists.
  • Do not commit Cloud reversal until the device result is definite.
  • Create sale reversal records after definite CANCELLED/REVERSED result.
  • The same idempotency key does not create stock/cash/payment reversal twice.
  • Original sale, payment, stock and cash rows remain.

Full Return

  • Return all remaining lines.
  • Block when device payment total cannot cover remaining return total.
  • Block device call when RelatedSaleId/ItemId/PaymentId references are missing.
  • Advance sale to RETURNED state.
  • Add returned quantity back to stock.

Partial Return

  • Return quantity cannot exceed remaining quantity.
  • Match line amount to device amount within 0.05 tolerance.
  • Advance sale to PARTIALLY_RETURNED state.
  • Later returns cannot exceed cumulative payment/quantity boundaries.
  • Same idempotency key does not create duplicate records.
CAPABILITIES

Device, Offline Queue and Result Safety

Offline Safety

  • Create local GUID-named JSON before device call.
  • Preserve RESULT_UNKNOWN on network/application interruption.
  • Do not blindly re-send RESULT_UNKNOWN.
  • Sync CLOUD_SYNC_PENDING to Cloud without re-running on the device.
  • Move corrupt JSON to quarantine.
  • GUID JSON must be discoverable after application restart.

Device Change

  • Clear sale list.
  • Clear selected sale/line and external references.
  • Clear adapter result.
  • Fetch again for the new device only on user command.

Device / Cloud Split

  • Definite device result is determined at device layer.
  • Cloud reversal is processed only after definite device result.
  • RESULT_UNKNOWN does not produce double processing in Cloud or device.
FAQ

Frequently asked questions

Can QShop and QAdisyon restaurant data mix?+

No. QShop store sales remain isolated from QAdisyon restaurant order operations.

What happens if the same sale-completion request is submitted twice?+

IDEMPOTENCY_KEY prevents a repeated completion request from creating duplicate sale, stock or payment movements and returns the completed sale instead.

Are original records deleted during returns?+

No. Original sale, payment, stock and cash records are preserved; reversal records are created when required.

What happens when the device response remains uncertain?+

RESULT_UNKNOWN is preserved and the operation is not blindly re-run on the device; the safe queue flow remains until a definite state is available.

QBS PARTNER NETWORK

Find a partner specialized in QShop.

The product showroom filters the authorized network by product capability.

Open partner showroom →

See QShop with your own scenario.

Book a demo →