簡(jiǎn)介一份面向計(jì)算機(jī)相關(guān)專業(yè)畢業(yè)設(shè)計(jì)使用的《超市收銀系統(tǒng)設(shè)計(jì)說明書》文檔類資源適合需要完成超市管理系統(tǒng)或收銀系統(tǒng)課程設(shè)計(jì)、畢業(yè)論文撰寫的學(xué)生參考。資源以docx文件形式呈現(xiàn)共1個(gè)文件壓縮包約500KB內(nèi)容涵蓋從需求分析、數(shù)據(jù)流圖、數(shù)據(jù)字典、實(shí)體聯(lián)系圖到系統(tǒng)概要設(shè)計(jì)、數(shù)據(jù)庫(kù)邏輯結(jié)構(gòu)設(shè)計(jì)、詳細(xì)人機(jī)交互設(shè)計(jì)及軟件測(cè)試等完整章節(jié)可作為畢業(yè)設(shè)計(jì)說明書撰寫模板和格式范例。已有152人瀏覽學(xué)習(xí)文檔結(jié)構(gòu)清晰可直接對(duì)照目錄查閱。其中對(duì)前臺(tái)收銀、后臺(tái)進(jìn)貨與庫(kù)存管理等模塊的劃分、數(shù)據(jù)庫(kù)表設(shè)計(jì)以及C#與VS2013開發(fā)環(huán)境的選擇均有具體論述能幫助讀者快速理解超市收銀系統(tǒng)的設(shè)計(jì)思路與文檔規(guī)范減少?gòu)牧阕珜懻撐牡臅r(shí)間成本。1. 超市收銀系統(tǒng)設(shè)計(jì)說明書一張表結(jié)構(gòu)決定收銀臺(tái)會(huì)不會(huì)排長(zhǎng)隊(duì)收銀臺(tái)卡頓、打折價(jià)算錯(cuò)、交接班對(duì)不平賬這些事在超市里幾乎每天發(fā)生多數(shù)門店把鍋甩給硬件老舊或者網(wǎng)絡(luò)差。做過收銀系統(tǒng)的都明白根子往往在那一份沒寫清楚的設(shè)計(jì)說明書——商品怎么建檔、折扣怎么疊加、退款走什么流程全要落在文字和表結(jié)構(gòu)里。這份標(biāo)題為“超市收銀系統(tǒng)設(shè)計(jì)說明書.docx”的文檔實(shí)際上是把進(jìn)銷存、收銀、支付、對(duì)賬、報(bào)表五個(gè)子系統(tǒng)用一份文檔鎖死讓開發(fā)、店長(zhǎng)、財(cái)務(wù)三方按同一套規(guī)則做事。適合準(zhǔn)備自建收銀系統(tǒng)的小型連鎖、接管理系統(tǒng)外包的團(tuán)隊(duì)以及想把現(xiàn)有收銀流程整理成可落地方案的產(chǎn)品和技術(shù)負(fù)責(zé)人。2. 從設(shè)計(jì)說明書拆出數(shù)據(jù)模型進(jìn)銷存與收銀的耦合關(guān)系超市收銀系統(tǒng)的數(shù)據(jù)模型決定了后面所有功能能不能長(zhǎng)出來。很多團(tuán)隊(duì)拿到設(shè)計(jì)說明書先畫頁(yè)面原型這是反的。收銀系統(tǒng)最值錢的部分是商品、庫(kù)存、價(jià)格、流水這四類數(shù)據(jù)的關(guān)系頁(yè)面只是數(shù)據(jù)的投影。2.1 商品主檔、庫(kù)存與價(jià)格三張表的字段邊界與主鍵策略商品主檔解決“賣的是什么”庫(kù)存表解決“還有多少”價(jià)格表解決“現(xiàn)在賣多少錢”。三張表職責(zé)不同最容易犯的錯(cuò)是往商品主檔里塞庫(kù)存數(shù)量和當(dāng)前售價(jià)。我一般會(huì)把商品主檔做成這樣CREATE TABLE product ( sku_id VARCHAR(32) PRIMARY KEY, -- 箱規(guī)維度SKU掃碼槍直接命中 barcode VARCHAR(32) NOT NULL, -- 69開頭的EAN-13條碼 product_name VARCHAR(128) NOT NULL, spec VARCHAR(64), -- 規(guī)格如500ml/瓶 unit VARCHAR(8) NOT NULL, -- 銷售單位瓶、包、袋 category_id INT NOT NULL, -- 分類決定報(bào)表匯總口徑 status TINYINT NOT NULL DEFAULT 1 -- 1上架 0下架 );注意主鍵用sku_id而不是條碼。原因是同一件商品可能有多套條碼整箱碼、單瓶碼、促銷碼條碼更適合做唯一索引而不是主鍵。掃碼槍掃到條碼后通過barcode查到唯一sku_id再走價(jià)格表取價(jià)。這樣換包裝、加促銷碼時(shí)不需要?jiǎng)由唐分麈I。庫(kù)存和價(jià)格要獨(dú)立成表CREATE TABLE stock ( sku_id VARCHAR(32) NOT NULL, store_id INT NOT NULL, -- 連鎖場(chǎng)景必須帶門店維度 quantity INT NOT NULL DEFAULT 0, locked_qty INT NOT NULL DEFAULT 0, -- 掛單/預(yù)定占用的庫(kù)存 PRIMARY KEY (store_id, sku_id) ); CREATE TABLE product_price ( sku_id VARCHAR(32) NOT NULL, price_type TINYINT NOT NULL, -- 1正常售價(jià) 2會(huì)員價(jià) 3促銷價(jià) price DECIMAL(10,2) NOT NULL, begin_time DATETIME NULL, end_time DATETIME NULL, PRIMARY KEY (sku_id, price_type) );庫(kù)存表不存金額價(jià)格表不存數(shù)量。這樣設(shè)計(jì)的好處是盤點(diǎn)只動(dòng)stock調(diào)價(jià)只動(dòng)product_price兩邊互不鎖。如果按“一張商品表帶庫(kù)存帶價(jià)格”來做每次改價(jià)都會(huì)觸發(fā)庫(kù)存行的更新并發(fā)高一點(diǎn)就會(huì)出現(xiàn)鎖等待收銀臺(tái)表現(xiàn)就是掃碼后轉(zhuǎn)圈。關(guān)鍵參數(shù)計(jì)價(jià)用DECIMAL(10,2)不要用FLOAT。收銀涉及金額累加和折扣分?jǐn)偢↑c(diǎn)數(shù)在“滿100減20再9折”這種嵌套計(jì)算里會(huì)出現(xiàn) 0.01 的誤差財(cái)務(wù)對(duì)賬時(shí)極難定位。寧可所有金額字段都定義成DECIMAL換來的是一年下來對(duì)賬不用靠“調(diào)賬”找平。2.2 交易流水與支付流水為什么不能合成一張表把交易流水和支付流水合成一張表是收銀系統(tǒng)早期最常見的敗筆?？瓷先ナ×艘淮尾迦氲鹊浇游⑿胖Ц丁⒅Ц秾?、現(xiàn)金三種支付方式后會(huì)發(fā)現(xiàn)一個(gè)訂單可能拆成“部分現(xiàn)金 部分掃碼”這時(shí)候一張表就怎么都塞不下了。正確做法是拆兩級(jí)結(jié)構(gòu)訂單級(jí)交易頭和支付級(jí)支付流水。CREATE TABLE sale_order ( order_id VARCHAR(32) PRIMARY KEY, -- 業(yè)務(wù)單號(hào)格式見下 store_id INT NOT NULL, cashier_id INT NOT NULL, order_time DATETIME NOT NULL, total_amount DECIMAL(10,2) NOT NULL, -- 商品原價(jià)合計(jì) discount_amount DECIMAL(10,2) NOT NULL DEFAULT 0, payable_amount DECIMAL(10,2) NOT NULL, -- 應(yīng)收 status TINYINT NOT NULL DEFAULT 1 -- 1已支付 2已退款 3掛單 ); CREATE TABLE payment_flow ( flow_id INT AUTO_INCREMENT PRIMARY KEY, order_id VARCHAR(32) NOT NULL, pay_type TINYINT NOT NULL, -- 1現(xiàn)金 2微信 3支付寶 4儲(chǔ)值卡 pay_amount DECIMAL(10,2) NOT NULL, trade_no VARCHAR(64), -- 微信/支付寶的渠道流水號(hào) paid_time DATETIME NOT NULL, refund_status TINYINT NOT NULL DEFAULT 0 -- 0無 1部分退 2全退 );訂單號(hào)生成建議用門店編號(hào)(3位) 收銀機(jī)編號(hào)(2位) 日期(YYYYMMDD) 流水號(hào)(4位)例如008-03-20250601-0012。這個(gè)格式的好處是從訂單號(hào)直接看出哪家店、哪臺(tái)機(jī)器、哪天、當(dāng)天第幾單排查問題時(shí)不需要翻數(shù)據(jù)庫(kù)查門店名稱。合表之后用一條 SQL 就能查“今天微信支付總金額”但如果未來要接入新的支付渠道比如數(shù)字人民幣或者銀行聚合支付合表就需要加字段加字段就會(huì)影響核心交易表的寫入性能。分開之后支付渠道的擴(kuò)展只是往payment_flow加一個(gè)pay_type枚舉值不動(dòng)訂單主表。設(shè)計(jì)說明書里如果只有“交易記錄”一張表一定要讓作者拆開。2.3 用 SQL 描述“買二贈(zèng)一”促銷規(guī)則怎么落庫(kù)“買二贈(zèng)一”這類促銷是收銀系統(tǒng)里最讓開發(fā)頭疼的需求。它跟打折不一樣打折是改單價(jià)買贈(zèng)是加商品而且贈(zèng)品的庫(kù)存也要扣。我的做法是把促銷規(guī)則抽成一張獨(dú)立的規(guī)則表不在商品表上加“促銷類型”字段因?yàn)橐粋€(gè)商品可能同時(shí)掛在多套促銷下CREATE TABLE promotion_rule ( rule_id INT PRIMARY KEY AUTO_INCREMENT, rule_name VARCHAR(64) NOT NULL, rule_type TINYINT NOT NULL, -- 1滿減 2折扣 3買贈(zèng) 4第N件優(yōu)惠 condition_qty INT NOT NULL DEFAULT 1, -- 滿X件 condition_amount DECIMAL(10,2) NULL, -- 滿X元與qty二選一 benefit_qty INT NULL, -- 買贈(zèng)贈(zèng)送X件 benefit_discount DECIMAL(10,2) NULL, -- 折扣打X折8.0表示八折 max_discount DECIMAL(10,2) NULL, -- 滿減封頂金額 begin_time DATETIME NOT NULL, end_time DATETIME NOT NULL, store_scope VARCHAR(100) NOT NULL DEFAULT * -- 適用門店*為全部 ); CREATE TABLE promotion_sku ( rule_id INT NOT NULL, sku_id VARCHAR(32) NOT NULL, PRIMARY KEY (rule_id, sku_id) );結(jié)算服務(wù)取規(guī)則時(shí)先按“當(dāng)前時(shí)間落在begin_time和end_time之間”過濾再按門店范圍過濾最后去promotion_sku查這個(gè)商品參與了哪些規(guī)則按優(yōu)先級(jí)排出最終生效的那一條。這里有個(gè)經(jīng)驗(yàn)買贈(zèng)的贈(zèng)品不要改庫(kù)存單價(jià)而是在訂單明細(xì)里插入一行數(shù)量為正、單價(jià)為 0 的商品并在這一行記錄來源promotion_rule_id。這樣后續(xù)盤點(diǎn)、毛利分析才能看出“贈(zèng)送出去多少”如果直接改主商品單價(jià)財(cái)務(wù)算毛利時(shí)完全是糊涂賬。2.4 數(shù)據(jù)字典必須在設(shè)計(jì)說明書里單獨(dú)占一章設(shè)計(jì)說明書如果只有流程圖和頁(yè)面描述沒有數(shù)據(jù)字典開發(fā)階段一定會(huì)出現(xiàn)“這里加個(gè)字段”的失控蔓延。規(guī)范的做法是在文檔里為每張核心表列字段清單字段名、類型、默認(rèn)值、是否可空、枚舉含義、備注。前面貼出的建表語(yǔ)句實(shí)際上就是數(shù)據(jù)字典的可執(zhí)行版本。寫文檔的時(shí)候要約定枚舉值的含義比如pay_type的 1 代表現(xiàn)金、2 代表微信、3 代表支付寶這個(gè)映射寫進(jìn)數(shù)據(jù)字典后前端、后端、對(duì)賬腳本都用同一份定義。否則就會(huì)出現(xiàn)后端返回pay_type2前端彈窗顯示“支付寶”的翻車現(xiàn)場(chǎng)。數(shù)據(jù)字典不要求在原型完成前就 100% 齊全但核心交易表必須在動(dòng)手寫第一行代碼前定稿。3. 把說明書拆成模塊與里程碑一份文檔驅(qū)動(dòng)整個(gè)收銀項(xiàng)目的排期拿到“超市收銀系統(tǒng)設(shè)計(jì)說明書”之后第一件事不是讀需求而是拆模塊。說明書通常按業(yè)務(wù)功能組織開發(fā)排期要按“數(shù)據(jù)依賴 驗(yàn)收閉環(huán)”組織兩者不是一回事。3.1 從說明書目錄反推系統(tǒng)邊界我拿到一份設(shè)計(jì)說明書先翻目錄確認(rèn)有沒有這些模塊基礎(chǔ)資料商品、供應(yīng)商、門店、采購(gòu)入庫(kù)、庫(kù)存管理、收銀結(jié)算、支付對(duì)接、會(huì)員營(yíng)銷、報(bào)表統(tǒng)計(jì)、系統(tǒng)權(quán)限。這八個(gè)模塊如果說明書里都有那它描述的是一個(gè)完整的小型連鎖收銀系統(tǒng)如果只有收銀和商品那它更像一個(gè)單店 POS 的需求。系統(tǒng)邊界定了之后模塊拆分才能談。我的拆分原則是每個(gè)模塊都能獨(dú)立演示一個(gè)業(yè)務(wù)閉環(huán)。比如“庫(kù)存管理”至少要能演示采購(gòu)入庫(kù)、盤點(diǎn)調(diào)整、銷售扣減三個(gè)動(dòng)作“收銀結(jié)算”至少要能演示掃商品、算折扣、混合支付、打印小票四個(gè)動(dòng)作。不能出現(xiàn)“這些功能要等報(bào)表模塊做完才能看效果”的說法。3.2 模塊依賴順序?yàn)槭裁瓷唐分鳈n先于收銀收銀先于支付模塊開發(fā)順序不要按說明書章節(jié)順序來要按依賴關(guān)系排。第一批做基礎(chǔ)資料和庫(kù)存。沒有商品主檔收銀臺(tái)沒法掃碼沒有庫(kù)存表入庫(kù)單無處可寫。這一批的驗(yàn)收標(biāo)準(zhǔn)是能通過管理端新增商品、調(diào)整庫(kù)存、查詢庫(kù)存流水。第二批做收銀核心鏈路。收銀臺(tái)掃商品、算價(jià)格、生成訂單、落交易流水。這一階段不接真實(shí)支付用“模擬支付成功”來打通訂單狀態(tài)流轉(zhuǎn)。很多人急著接微信支付結(jié)果訂單狀態(tài)還沒設(shè)計(jì)好支付回調(diào)來了不知道往哪寫這是本末倒置。第三批接支付與對(duì)賬。真實(shí)支付接入后才有支付流水、退款、隔日對(duì)賬這些事。支付回調(diào)要能自動(dòng)匹配訂單號(hào)匹配不上的進(jìn)異常賬池人工處理。第四批做報(bào)表和權(quán)限。這一步放在最后因?yàn)閳?bào)表依賴前面的數(shù)據(jù)積累權(quán)限控制依賴角色和操作日志的定義。3.3 里程碑與驗(yàn)收標(biāo)準(zhǔn)每個(gè)階段能演示什么用設(shè)計(jì)說明書作為項(xiàng)目合同的話每個(gè)里程碑都要有可勾選的驗(yàn)收清單。比如第二個(gè)里程碑“收銀核心鏈路”的驗(yàn)收項(xiàng)至少包括掃碼槍掃 EAN-13 條碼能命中商品命中失敗有提示音。同一商品連續(xù)掃 3 次訂單明細(xì)合并成一行、數(shù)量累加為 3。商品單價(jià)取自product_price中當(dāng)前時(shí)間有效的促銷價(jià)不是商品主檔里的字段。現(xiàn)金支付找零金額小數(shù)部分不超過兩位。模擬支付成功后sale_order.status變更為已支付payment_flow生成一條記錄。驗(yàn)收不通過就繼續(xù)迭代不要帶著半成品進(jìn)入支付聯(lián)調(diào)。很多項(xiàng)目拖期的原因就是前一個(gè)模塊的欠賬壓在后面最后所有問題都在上線前爆發(fā)。4. 收銀系統(tǒng)必調(diào)的 5 個(gè)業(yè)務(wù)參數(shù)價(jià)格、折扣與退換貨的邊界設(shè)計(jì)說明書寫得再完整落到系統(tǒng)里也得有幾百個(gè)業(yè)務(wù)參數(shù)。收銀系統(tǒng)里最敏感的是下面這 5 類調(diào)錯(cuò)了直接體現(xiàn)為金額算錯(cuò)或?qū)~不平。4.1 折扣疊加優(yōu)先級(jí)滿減、會(huì)員價(jià)、限時(shí)秒殺的正確執(zhí)行順序促銷疊加是收銀系統(tǒng)最大的“黑匣子”。不做約束的話滿 100 減 20 的活動(dòng)會(huì)和會(huì)員價(jià)、限時(shí)秒殺同時(shí)生效出現(xiàn)“5 折之后再滿減結(jié)算金額為負(fù)”的極端結(jié)果。我的經(jīng)驗(yàn)是把促銷執(zhí)行順序做成可配置的優(yōu)先級(jí)而不是寫死在代碼里。常見順序是優(yōu)先級(jí)促銷類型說明1限時(shí)秒殺/直降直接改商品銷售價(jià)不可與會(huì)員價(jià)疊加2會(huì)員價(jià)未命中秒殺時(shí)生效標(biāo)記為會(huì)員專享3滿減按訂單金額階梯扣減可與其他券疊加但設(shè)上限4折扣按商品行打折在滿減之后計(jì)算5抹零最后一步處理不參與折扣計(jì)算每一項(xiàng)都要設(shè)置“是否可疊加”的開關(guān)。比如秒殺商品不允許參與滿減這是行業(yè)里的硬規(guī)則必須在參數(shù)里強(qiáng)制不能依賴收銀員現(xiàn)場(chǎng)判斷。收銀員在結(jié)賬時(shí)看到的價(jià)格應(yīng)該是系統(tǒng)算好的一口價(jià)而不是由她心算疊加結(jié)果。4.2 抹零與舍入分賬對(duì)不上的元兇抹零看似簡(jiǎn)單實(shí)際坑很深。常見做法是“應(yīng)付金額抹去分位”比如 10.56 元抹零為 10.50 元。但支付平臺(tái)是按照實(shí)付金額結(jié)算的如果抹零在本地做支付渠道側(cè)的錢和本地訂單金額差 0.06 元日終對(duì)賬就出現(xiàn)一筆“未知名目的長(zhǎng)款”。我在設(shè)計(jì)說明書里的約定是抹零只允許作用于現(xiàn)金支付掃碼支付不做抹零。因?yàn)楝F(xiàn)金交易不產(chǎn)生第三方對(duì)賬單抹零的損失由門店承擔(dān)屬于營(yíng)銷成本掃碼支付的每一分錢都要和渠道對(duì)賬單對(duì)上抹零會(huì)讓自動(dòng)對(duì)賬腳本罷工。如果一定要對(duì)掃碼支付做抹零就把抹零金額單獨(dú)記錄到一張discount_detail表注明“抹零-現(xiàn)金”或“抹零-掃碼”日終對(duì)賬時(shí)把這筆金額排除掉并且每天匯總抹零總額給財(cái)務(wù)確認(rèn)。4.3 退款、原路退回與沖正庫(kù)存回滾的邊界退款的難點(diǎn)不在退款動(dòng)作本身而在庫(kù)存回滾和支付原路退回的時(shí)序。設(shè)計(jì)說明書里必須寫清楚整單退款時(shí)訂單明細(xì)里每件商品庫(kù)存在什么時(shí)間點(diǎn)加回去部分退款時(shí)退掉的商品數(shù)量和剩余商品數(shù)量怎么區(qū)分。我的做法是訂單明細(xì)增加refunded_qty字段每次退款先把數(shù)量記上再異步回滾庫(kù)存。先記退款再回滾庫(kù)存避免回滾失敗導(dǎo)致重復(fù)加庫(kù)存。原路退回要區(qū)分支付渠道?，F(xiàn)金支付的退款直接在收銀臺(tái)操作讓收銀員從錢箱退款并在系統(tǒng)里記錄微信支付寶支付的退款要么調(diào)渠道 API 原路退回要么生成退款單讓財(cái)務(wù)線下轉(zhuǎn)賬。設(shè)計(jì)說明書如果寫的是“所有退款都原路退回”上線前一定要確認(rèn)聚合支付服務(wù)商是否支持部分退款很多渠道部分退款有次數(shù)和時(shí)間限制不支持的話就要有線下處理兜底。4.4 掛單、鎖單與離線收銀收銀臺(tái)最容易被忽略的三個(gè)開關(guān)掛單功能在早市和高峰期特別重要。顧客買了一半發(fā)現(xiàn)忘帶東西收銀員點(diǎn)掛單下一單結(jié)完再恢復(fù)。掛單設(shè)計(jì)有幾個(gè)細(xì)節(jié)掛單數(shù)量上限默認(rèn)給 10 單多了收銀界面會(huì)卡掛單訂單要鎖定已掃描商品的庫(kù)存否則會(huì)被其他收銀臺(tái)賣完。離線收銀是連鎖超市必須有的能力斷網(wǎng)時(shí)收銀臺(tái)變成獨(dú)立模式商品價(jià)格從本地緩存讀取訂單寫入本地隊(duì)列支付只接受現(xiàn)金。網(wǎng)絡(luò)恢復(fù)后本地訂單上傳到服務(wù)端服務(wù)端按order_id去重合并。設(shè)計(jì)說明書如果沒寫離線模式上線后門店一斷網(wǎng)就變成手寫小票財(cái)務(wù)晚上對(duì)賬就會(huì)崩。4.5 價(jià)格審計(jì)日志誰(shuí)在什么時(shí)間改了什么價(jià)調(diào)價(jià)權(quán)限是收銀系統(tǒng)里最容易漏的審計(jì)點(diǎn)。門店店長(zhǎng)能不能直接改商品售價(jià)如果能改價(jià)操作必須留痕。我在系統(tǒng)里做了一張price_change_log每次修改product_price都記錄操作人、門店、商品、原價(jià)、新價(jià)、生效時(shí)間、操作終端 IP。財(cái)務(wù)月結(jié)時(shí)要能查到“上周三 14:05 誰(shuí)把可口可樂從 3.5 改成了 2.9持續(xù)了多久”。這個(gè)日志表不需要在收銀鏈路里查詢只對(duì)管理端和審計(jì)導(dǎo)出可見但數(shù)據(jù)要實(shí)時(shí)寫入不能攢批。沒有審計(jì)日志的促銷系統(tǒng)被員工利用改價(jià)漏洞刷單后財(cái)務(wù)連證據(jù)都拿不出來。5. 收銀系統(tǒng)避坑指南并發(fā)、對(duì)賬、數(shù)據(jù)遷移與硬件適配的翻車現(xiàn)場(chǎng)收銀系統(tǒng)上線前后最容易翻車的不是業(yè)務(wù)邏輯而是并發(fā)數(shù)據(jù)一致性、對(duì)賬偏差、老系統(tǒng)遷移和硬件兼容。這部分的問題多數(shù)是“現(xiàn)象明顯根因埋在其他模塊里”排查起來特別費(fèi)勁。5.1 峰值并發(fā)扣庫(kù)存樂觀鎖和事務(wù)鎖怎么選現(xiàn)象門店促銷日收銀臺(tái)同時(shí)提交訂單后臺(tái)庫(kù)存扣減出現(xiàn)負(fù)數(shù)或者同一件商品被兩臺(tái)機(jī)器同時(shí)賣掉后付款的顧客只能退款。原因庫(kù)存扣減用的是“先查庫(kù)存再減庫(kù)存”兩步操作兩個(gè)請(qǐng)求同時(shí)讀到庫(kù)存等于 1各自減 1結(jié)果變成 0 而不是 -1。解決扣庫(kù)存 SQL 必須用原子的條件更新UPDATE stock SET quantity quantity - 1 WHERE store_id 8 AND sku_id 692000000001 AND quantity 1;quantity 1這個(gè)條件讓數(shù)據(jù)庫(kù)在更新時(shí)做并發(fā)檢查如果影響行數(shù)為 0說明庫(kù)存不足收銀端攔截。這是樂觀鎖思路在庫(kù)存場(chǎng)景的變體比在應(yīng)用層加分布式鎖簡(jiǎn)單得多。注意不要把locked_qty和quantity混在一個(gè) UPDATE 里做多行計(jì)算先扣鎖定再扣可用順序?qū)懬宄駝t高壓下會(huì)出現(xiàn)鎖定數(shù)量為負(fù)的臟數(shù)據(jù)。5.2 日結(jié)對(duì)賬不平支付回調(diào)與本地流水的時(shí)間窗口現(xiàn)象每天 23:00 對(duì)賬本地訂單顯示“已支付”渠道賬單里查不到或者渠道賬單里有一筆本地訂單狀態(tài)還是“待支付”。原因支付回調(diào)是異步的顧客掃碼付完錢渠道的回調(diào)可能需要幾秒才到達(dá)本地服務(wù)。如果對(duì)賬腳本恰好在這個(gè)時(shí)間窗口里跑了兩邊數(shù)據(jù)就不一致。解決對(duì)賬不要把“本地訂單狀態(tài)”當(dāng)成唯一依據(jù)。正確做法是把payment_flow中的trade_no和渠道賬單按天做全量比對(duì)本地有而渠道沒有的單據(jù)標(biāo)記為“待確認(rèn)”隔 30 分鐘再查一次渠道訂單狀態(tài)渠道有而本地沒有的走“人工認(rèn)領(lǐng)”流程先確認(rèn)是否漏單。對(duì)賬腳本只做標(biāo)記不做自動(dòng)改單改單必須人工確認(rèn)后執(zhí)行否則誤把正在支付中的訂單標(biāo)記為失敗就會(huì)引發(fā)客訴。5.3 老系統(tǒng)數(shù)據(jù)遷移編碼混亂、重復(fù)單號(hào)與歷史庫(kù)存差異現(xiàn)象新系統(tǒng)上線第一天商品檔案導(dǎo)入了他的編碼庫(kù)存也是按供應(yīng)商給的 Excel 錄入的。開業(yè)第三天盤點(diǎn)發(fā)現(xiàn) 300 個(gè) SKU 數(shù)量和實(shí)際對(duì)不上。原因老系統(tǒng)和新系統(tǒng)的商品編碼規(guī)則不一致。老系統(tǒng)用九位編碼新系統(tǒng)用 SKU 條碼雙主鍵導(dǎo)入時(shí)只帶了條碼和歷史庫(kù)存沒帶歷史成本價(jià)。加上老系統(tǒng)一年沒做清點(diǎn)庫(kù)存數(shù)本身就是錯(cuò)的。解決遷移時(shí)不要把歷史庫(kù)存當(dāng)“期初數(shù)據(jù)”要先做一次實(shí)物盤點(diǎn)用盤點(diǎn)結(jié)果做期初。歷史庫(kù)存只用來做參考和對(duì)賬看板。商品編碼要建立對(duì)照表老編碼、新 SKU、條碼、名稱、規(guī)格五列缺一不可。遷移完成后先跑一遍“無主商品”查詢把所有條碼在舊表中存在但新表里沒有對(duì)應(yīng)關(guān)系的數(shù)據(jù)找出來人工補(bǔ)全后再正式開放收銀。5.4 硬件適配小票打印機(jī)、錢箱與掃碼槍的兼容坑現(xiàn)象新收銀臺(tái)裝好了小票打印機(jī)連不上或者錢箱打不開掃碼槍掃條碼經(jīng)常多打一個(gè)回車導(dǎo)致收銀界面跳單。原因小票打印機(jī)驅(qū)動(dòng)用的指令集不兼容。超市收銀最常用的是 ESC/POS 指令但不同品牌的實(shí)現(xiàn)有差異尤其是切紙和錢箱開閘指令GS V和ESC p兩種指令不能混用。掃碼槍默認(rèn)開啟了回車后綴收銀臺(tái)界面綁定的是 Enter 鍵觸發(fā)結(jié)賬于是掃完商品直接彈到支付頁(yè)。解決統(tǒng)一采購(gòu)支持 ESC/POS 的打印機(jī)小票打印走qpos58這類通用驅(qū)動(dòng)不要每臺(tái)設(shè)備單獨(dú)寫驅(qū)動(dòng)適配。錢箱開閘用打印機(jī)的錢箱口通過 ESC/POS 指令控制別用 USB 繼電器。掃碼槍設(shè)置里把后綴從回車改成 Tab或者在收銀臺(tái)輸入框綁定keydown事件攔掉物理回車。硬件測(cè)試清單里必須有“打印小票 100 張無卡紙”“錢箱連續(xù)開關(guān) 50 次”“掃碼槍掃 300 個(gè)條碼無重碼”三條這比任何軟件測(cè)試都更早暴露問題。6. 從說明書到上線檢查表六個(gè)最容易漏的驗(yàn)收項(xiàng)設(shè)計(jì)說明書里最后往往有一章“其他要求”所有坑都藏在這里。我自用的收銀系統(tǒng)上線檢查表有六項(xiàng)每一項(xiàng)都是過去踩過坑換來的交接班日結(jié)。早班和晚班交接時(shí)收銀員各自打印當(dāng)班小計(jì)系統(tǒng)能按“收銀員 班次”獨(dú)立統(tǒng)計(jì)收款金額且現(xiàn)金差額能錄入備注。沒有這一項(xiàng)門店每天短款長(zhǎng)款全是糊涂賬。斷網(wǎng)演練。拔掉網(wǎng)線收銀臺(tái)要能用緩存商品繼續(xù)結(jié)賬 2 小時(shí)網(wǎng)絡(luò)恢復(fù)后自動(dòng)上傳訂單不重復(fù)、不丟單。上不了這一條說明離線模塊沒做完。退款權(quán)限分級(jí)。收銀員只能退當(dāng)班當(dāng)?shù)暧唵蔚觊L(zhǎng)能退本店近 30 天訂單區(qū)域經(jīng)理才可跨店退貨。每一檔權(quán)限要對(duì)應(yīng)一次短信/應(yīng)用內(nèi)審批不然退款漏洞會(huì)被薅到關(guān)店。商品改價(jià)審計(jì)。查 24 小時(shí)內(nèi)所有price_change_log確認(rèn)每一筆調(diào)價(jià)都有授權(quán)記錄。沒有日志的商品等于沒有改價(jià)功能。數(shù)據(jù)庫(kù)備份恢復(fù)演練。至少做過一次從備份文件恢復(fù)到測(cè)試庫(kù)的完整流程恢復(fù)后數(shù)據(jù)不能只恢復(fù)到凌晨而是恢復(fù)到最近一次“全量 增量”的合并點(diǎn)。從沒演練過的備份方案等于沒有備份。促銷日歷生效。把“6 月 1 日零點(diǎn)全場(chǎng) 9 折”配置好驗(yàn)證 23:59 的訂單是原價(jià)、00:00 的訂單是折扣價(jià)。促銷時(shí)間邊界差一分鐘大促當(dāng)天就是投訴熱點(diǎn)。經(jīng)驗(yàn)里最疼的一次是老系統(tǒng)的庫(kù)存數(shù)據(jù)遷移生產(chǎn)環(huán)境已經(jīng)切過去盤點(diǎn)才知道期初庫(kù)存錯(cuò)了兩百多件后臺(tái)調(diào)賬調(diào)了整整一周。這之后我的原則就一句話能用盤點(diǎn)結(jié)果做期初的絕不用 Excel 數(shù)據(jù)能先跑一輪全鏈路演練的絕不直接上生產(chǎn)。收銀系統(tǒng)這種直接碰錢的項(xiàng)目設(shè)計(jì)說明書是起點(diǎn)但真正決定成敗的是表結(jié)構(gòu)、促銷規(guī)則、對(duì)賬邏輯和遷移邊界。希望這份拆解和檢查清單能幫到你少走幾步我們當(dāng)時(shí)繞遠(yuǎn)的路。本文還有配套的精品資源點(diǎn)擊獲取