BIZARRE BAZAARTianjin · Operations
BIZARRE BAZAAR · TIANJIN · OPERATIONS

How the systems connect

Flow: price list → order → ERP → warehouse → stock → statistics.

1. Order journey

client → warehouse
1Price listbbprice: the client fills a cart and submits an order (POST /order.pdf)
2Price ordersorders table in bb_reg.db: number, client, lines, total
3ERP · Site orderscollected when the page opens, no duplicates (ext_id UNIQUE)
4Draft invoice“To invoice” button: client, lines, prices from the price list
5Postingadmin in ERP: approved=1 and stock movements in one transaction

Order lines are matched to ERP items by the Chinese name. If an item is missing the line is skipped and the invoice stays a draft for the manager to fix.

2. Warehouse stock

one formula

Stock = sum of all moves for an item and warehouse. There is no other source — ERP, warehouse and manager desk all read the same view v_stock.

OperationWhereWritesStock
Receipt (delivery)Warehouse, ERPmoves.kind=in+
Sale / shipmentERP, invoice postingmoves.kind=out−
Write-off (damage)Warehousekind=writeoff−
Transfer between warehousesWarehousekind=move, wh_id → wh_to0
StocktakeERP, invoice postingkind=adjust±

The warehouse never goes negative: stock is checked before writing off. A sale reduces stock only when the invoice is posted, not when it is drafted.

3. Four managers at once

what was done for it
WhatHow
Separate accountsERP → Users: login, password, role admin / manager / staff, blocking. One admin owns catalogues and people.
Own documentsEvery draft records its author (sales.user); a manager sees own invoices, admin sees all.
Concurrent writesSQLite in WAL mode, busy_timeout 10 s: readers never block writers, writers queue instead of failing with “database is locked”.
Document numbersXSCK-YYYYMMDD-00001; on a collision the insert retries with a new number (up to 6 tries) — no race.
No double postingPosting is one BEGIN IMMEDIATE transaction guarded by approved=0. The second manager gets “already posted”, movements never duplicate.
Action historyEvery action is written to audit with the login: who posted, who wrote off, who created a user.

Practice: 4 managers create orders and drafts, posting is a single point (admin). That rules out double write-offs and stock drift without locks or waiting.

4. Where things live

domains
SystemAddressData
Control centrehub.redbutton.beerreads both databases, changes nothing
ERPerp2.redbutton.beerbb_erp.db
Warehousestock.redbutton.beerbb_erp.db · moves
Manager deskmanager.redbutton.beerbb_erp.db · drafts
Price listbbprice.redbutton.beerbb_reg.db · orders