jtricerolph 8d688b459d Initial kitchen scaffold — Phase 1 kitchen port (build-verified 2026-07-11)

FastAPI backend (Python 3.11, MSSQL ODBC for SambaPOS, Azure DI OCR),
kitchen_db on central PG. React/TS/Vite frontend with navy sidebar layout.

Backend: auth.py (APP_SLUG=kitchen, SimpleNamespace — archive routes use
.kitchen_id/.is_admin without modification), main.py (51 migrations, scheduler,
internal router for KDS bookings feed), api/internal.py, full archive API
(31 routers: invoices, recipes, menus, sambapos, resos, newbook, disputes,
purchase_orders, etc.), models, migrations, OCR pipeline.
kitchen_id pinned to 1 (B1 — single hotel).

Frontend: AuthGate (app=kitchen, token shim for archive compat — B5b pending),
Layout (navy sidebar, 6 sections, Lucide icons, teal --app-primary),
App.tsx (Outlet pattern, UploadApp outside Layout), index.css (full :root block).
strict: false — archive components have type issues; build clean.

Note: 45 archive components call fetch('/api/...') without /kitchen/ prefix
(B5b). Runtime 404s; deferred until after initial testing.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

2026-07-12 12:15:39 +00:00

2.3 KiB

Raw Blame History

Plan 3: SambaPOS Database Replication - Implementation Plan (Draft)

Status: On hold - needs further consideration on approach

Overview

Implement selective data replication from SambaPOS SQL Server to local PostgreSQL following Option B from PLAN_3. This reduces EPOS load, preserves historical data after clears, enables offline access, and includes SambaPOS data in Nextcloud backups.

Current State

Existing Implementation: backend/services/sambapos_api.py

SambaPOSClient class with direct MSSQL queries via aioodbc
Real-time queries for categories, top sellers, GL codes, restaurant spend
No local caching or replication
Data lost when SambaPOS clears database periodically

Connection Settings: backend/models/settings.py:76-88

sambapos_db_host, sambapos_db_port, sambapos_db_name, sambapos_db_username, sambapos_db_password

Open Question

Should we:

Create new PostgreSQL tables with normalized schema (PLAN_3 Option B)
Mirror exact SambaPOS schema to reuse existing queries
Add local SQL Server container (zero query changes)
Just do periodic archives for backup (simplest)

Implementation Phases (if proceeding with Option B)

Phase 1: Database Models

New File: backend/models/sambapos_replica.py

Create 8 SQLAlchemy models:

SambaposReplicationSettings - Sync config and tracking
SambaposTransaction - Sales, refunds, voids
SambaposPayment - Payment types and amounts
SambaposTicket - Order headers
SambaposTicketItem - Line items with order tags
SambaposMenuItem - Product catalog
SambaposAccount - Customer accounts, hotel rooms
SambaposArchive - Full database snapshot metadata

Phase 2: Replication Service

New File: backend/services/sambapos_replicator.py

Phase 3: Background Scheduler

New File: backend/services/sambapos_scheduler.py

Phase 4: Update SambaPOS API Service

Phase 5: Backup Integration

Phase 6: Frontend Settings UI

Success Criteria

SambaPOS data replicated to local PostgreSQL
Automatic sync every 15 minutes (configurable)
Reports can query replica instead of live database
Historical data preserved after SambaPOS clears
Backups include all replicated data
Settings UI shows sync status and allows manual trigger
Fallback to live database if replica empty

2.3 KiB Raw Blame History