从Word文档到SQLite仓储系统：字段拆解、事务与对账实践

简介：这是一份基于SQL Server 2005的仓储物资管理系统课程设计说明书，完整覆盖需求分析、概念结构设计、逻辑设计、物理设计与系统调试全过程。它面向数据库课程设计学习者、仓储信息化项目初学者以及需要完成同类设计报告的高校学生，尤其适合用于理解中小型管理系统从0到1的构建路径。资源以单个doc文档形式提供，压缩包约380KB，目前已有211人学习下载。文档围绕供应商、物资、员工、客户四类核心数据展开，详细描述了基本信息、仓库管理、供应商管理、客户管理、员工管理、物资信息、报表管理、系统维护八大功能模块，并展开商品信息查询、入库出库登记、退货与库存查询、员工薪资与值勤管理、数据安全与权限设置等子模块的具体设计。同时包含供应商代码、商品代码等数据字典，并给出技术可行性、运行可行性和软硬件环境分析（如Windows XP、2G内存）。整体方案具有较高可靠性、安全性与易维护性，对巩固SQL Server建库、表关系设计和数据库调试能力有直接帮助。

1. 拿到手是一份 .doc，先别当文档读，把它当第一版数据字典

「仓储物资管理系统.doc」这个标题，在真正做系统的人眼里不是一篇 Word 那么简单，而是一张还没画完的 ER 图。入库单、出库单、盘点表、物资台账全躺在表格里，真正的仓储物资管理系统要做的事，是把这些 Word 表格拆成字段、定好类型、加上约束，让每一笔出入库都经得起回查。这套方案适合手里只有历史 .doc、想用最少成本落地一套能跑的物料账目的工程师或仓库管理员；也适合想接着做二次开发，但需要先把字段口径统一的团队。下面不套框架，直接从文档表格出发，搭一套能交付、能对账的最小系统。

2. 从 .doc 拆出系统清单：Word 表格结构就是第一版数据字典

一份典型的仓储物资管理系统 .doc 里，至少躺着四类表：物资台账、入库单、出库单、盘点表。物资台账记录编号、名称、规格、单位、库存数；入库单和出库单记录单据号、经办人、日期、明细行；盘点表则记录盘点日期、账面数、实盘数、差异数。这四类表合起来，基本覆盖一个小型仓储系统的全部领域对象，后续建数据库表，本质就是把 Word 里的行列换成字段和约束。

先别急着写代码。我一般会先把每张 Word 表格的列名抄出来，做成一份“字典草稿”，这一步决定了后面建表、写接口、做报表的顺畅程度。比如入库单里常见的列是“物资编号、物资名称、单位、入库数量、入库日期、经办人”，出库单则多了“领用人”或“用途”。把它们分开整理，不要混在一张表里，因为单据表和台账表在实际系统里是两种不同的数据形态。单据表描述一次动作，台账表描述当前状态，混在一起后面写 SQL 时要拆开重来，成本翻倍。

2.1 文档里的四种表格，先分清台账与流水

台账是“当前状态”：每种物资现在有多少、放在哪个库位、单价和单位是什么。流水是“发生过的事”：某天某单入库 30 件，某天某单出库 12 件。状态会变，流水追加不改。台账可以由流水重新累加得出，所以设计阶段必须决定：库存表冗余成一张表，还是只保留流水、按需聚合。这是一个必须做的选择，而且直接影响后续所有报表逻辑。

我的默认做法是保留 inventory 表和 stock_flow 表双写：库存表负责快速查询和界面展示，流水表负责审计和追溯。这样做的代价是写操作多一步，好处是月底盘点、异常对账时不用从零扫流水。对 .doc 迁移过来的中小型仓储业务，数据量在十万级流水以内，双写完全扛得住，不必引入消息队列或触发器等重型机制。如果只留流水表，每次查询库存都要做 SUM 聚合，库存条目一多，界面会明显变慢，排查问题也更吃力。

盘点表单独拆出来比较少见，但实际业务里非常重要。盘点表至少要有盘点库位、实物数、账面数、差异数和处理意见。很多从 .doc 起步的系统第一版不做盘点，等到账实不符时只能认栽。我强烈建议在建表的第一版就把盘点记录留出来，后面做对账才有关键证据。盘点差异里，盘盈和盘亏的处理逻辑不一样：盘亏要查明原因、走审批、做库存扣减；盘盈同样要走反向调整，不能直接在数据库里把数量改大。这个流程一开始不做，后面每天都会有“库存不对”的投诉。

2.2 把 .doc 转成 .docx 再用 python-docx 提取表格，输出 JSON

python-docx 只能读 .docx，老版本 .doc 要先转换。常见做法是用 LibreOffice 命令行批量转换，命令如下：

libreoffice --headless --convert-to docx --outdir ./converted ./source/仓储物资管理系统.doc

这条命令的关键参数有三个：--headless 表示不弹图形界面，适合服务器和批处理场景；--convert-to docx 指定输出格式；--outdir ./converted 指定输出目录，文件会保持原文件名，只是后缀变成 .docx。转换完成后，用 python-docx 读取表格：

import json from docx import Document doc = Document("./converted/仓储物资管理系统.docx") tables_meta = [] for idx, table in enumerate(doc.tables): rows = [] for row in table.rows: cells = [cell.text.strip().replace("\n", " ") for cell in row.cells] rows.append(cells) tables_meta.append({ "table_index": idx, "table_rows": rows, }) with open("./schema_draft.json", "w", encoding="utf-8") as f: json.dump(tables_meta, f, ensure_ascii=False, indent=2)

这段脚本只做一件事：把 .docx 里的全部表格按顺序导出成 JSON。table.rows 遍历每一行，row.cells 取出该行所有单元格，strip() 去掉首尾空格，replace("\n", " ") 把单元格内的换行压成空格，方便后续人工阅读。输出文件的编码固定为 UTF-8，ensure_ascii=False 保证中文直接可读。运行后打开 schema_draft.json，就得到了一份“中文列名清单”，这是后续建立字段映射的重要基础。

有个细节需要提醒：合并单元格在 python-docx 里会出现同一个 cell 对象在多个位置重复返回，如果直接把 cells 平铺成行，会发现表格错位。遇到这种情况，不要急着写通用解析，先人工观察 JSON 输出里重复的文本，再决定是去重还是按位置补空。后面第 5 章会专门展开这个坑。

2.3 字段命名与类型选型：物资编号用 TEXT 主键，数量用 REAL

从 .doc 里抄出来的列名一般是中文，直接拿来做字段名也可以，但在 SQL 和 Python 代码里写中文字段会非常别扭，而且不同环境对 unicode 表名的支持参差不齐。我习惯把中文列名映射成英文小写加下划线：物资编号 → material_code，物资名称 → material_name，规格型号 → spec，单位 → unit，库存数量 → quantity。这层映射关系单独存一份配置，不要散落在代码里。

类型的坑主要在数量和编号上。数量字段建议使用 REAL，不要用 INTEGER。原因很直接：五金、线缆、化工原料经常出现小数计量，比如“2.5 卷”“0.8 吨”；用 INTEGER 会在程序里被迫引入大量换算逻辑，折算单位又容易出账差。金额字段另说，金额涉及精度和对账，应当用 NUMERIC 并统一保留两位小数，避免浮点误差累积。

物资编号看起来很像是自增主键的候选人，但从 .doc 迁移过来的系统里，编号往往是业务上长期沿用的编码，比如“C-2024-001”，出库单和盘点表都引用这串编码。如果把自增 id 当主键，而业务编号只做普通字段，那么所有关联表都要同时存两个值：自增 id 和业务编号，查询时还得来回翻译。对这套系统来说，直接用 material_code TEXT 做主键反而更自然。前提是确认编号在历史账里没有重复；一旦发现重复，必须先做清洗，否则建表会在第一步就失败。

提示：物资编号先跑一遍去重再建主键。SQLite 建完表再改主键代价很大，趁数据量小的时候处理最省事。

3. 搭最小仓储系统：SQLite 建表、事务化入库出库与库存对账

数据字典理清之后，就可以建库了。仓储物资管理系统第一版我推荐用 SQLite，不引入 MySQL 或 PostgreSQL。理由有三：单机可跑，迁移 .doc 数据时可以直接复用文件路径；建表和测试成本低，适合快速验证字段；后续要换 MySQL，SQL 大体兼容，只需要把 ENGINE、时间函数和小数类型做少量调整。下面用一个完整的建表脚本把核心结构固定下来。

3.1 三张表：inventory、bills、stock_flow 的设计与建表 SQL

先说表关系。inventory 保存每种物资的当前库存，是给人和界面看的“快照”；bills 保存每一张入库单或出库单的主表信息，包括单号、类型、经办人和时间；stock_flow 保存单据下的每一行明细，是审计和追溯的基础。三张表中，stock_flow 与 bills 关联，同时通过 material_code 与 inventory 关联。

PRAGMA foreign_keys = ON; CREATE TABLE IF NOT EXISTS inventory ( material_code TEXT PRIMARY KEY, material_name TEXT NOT NULL, spec TEXT, unit TEXT NOT NULL DEFAULT '件', category TEXT, quantity REAL NOT NULL DEFAULT 0 CHECK (quantity >= 0), updated_at TEXT NOT NULL DEFAULT (datetime('now', 'localtime')) ); CREATE TABLE IF NOT EXISTS bills ( doc_no TEXT PRIMARY KEY, doc_type TEXT NOT NULL CHECK (doc_type IN ('IN', 'OUT', 'CHECK')), operator TEXT NOT NULL, created_at TEXT NOT NULL DEFAULT (datetime('now', 'localtime')), remark TEXT ); CREATE TABLE IF NOT EXISTS stock_flow ( flow_id INTEGER PRIMARY KEY AUTOINCREMENT, doc_no TEXT NOT NULL, material_code TEXT NOT NULL, flow_type TEXT NOT NULL CHECK (flow_type IN ('IN', 'OUT')), quantity REAL NOT NULL CHECK (quantity > 0), before_qty REAL NOT NULL, after_qty REAL NOT NULL, operator TEXT NOT NULL, created_at TEXT NOT NULL DEFAULT (datetime('now', 'localtime')), FOREIGN KEY (doc_no) REFERENCES bills(doc_no), FOREIGN KEY (material_code) REFERENCES inventory(material_code) );

这段 SQL 有三个值得说的点。第一，inventory 上加了 CHECK (quantity >= 0)，让数据库在源头拒绝负库存；这一步看着简单，能挡掉大量程序逻辑漏判。第二，stock_flow 同时记录 before_qty 和 after_qty，这是对账的关键字段；没有这两个字段，出问题时就只能靠推测，查不了账。第三，bills 的 doc_type 限制了 IN、OUT、CHECK 三种类型，CHECK 表示盘点差异调整，避免“盘盈盘亏用什么单据”这类口径分歧。

外键约束要配合 PRAGMA foreign_keys = ON 使用。SQLite 默认不打开外键，很多人建了 FOREIGN KEY 却完全不起作用，删除单据时流水还在，最后数据出现孤儿行。这个 PRAGMA 要在每个连接建立后执行一次，Python 里可以用连接初始化回调统一处理。我见过最典型的翻车现场是：建表语句里外键写得很好看，实际跑了一年，删除单据后流水还在，手工对账时永远多出一批数据。

3.2 入库出库的事务边界：先查库存再扣减，流水与库存同时提交

库存系统的并发一致性问题，归根到底是“查、改、写流水”这三步能不能一起成功或一起失败。如果先更新库存，再插入流水，中间任何一步报错，账面和流水就对不上；如果先写流水再扣库存，库存不足时流水已经留痕，又得回滚。最稳妥的做法是把这几步放进同一个数据库事务里。

下面是一段 Python 实现，使用 sqlite3 的 with conn 上下文管理器，它会在代码块正常结束时自动 commit，异常时自动 rollback：

import sqlite3 def stock_out(conn, material_code, qty, doc_no, operator): if qty <= 0: raise ValueError("出库数量必须大于 0") with conn: cur = conn.execute( "SELECT quantity FROM inventory WHERE material_code = ?", (material_code,) ) row = cur.fetchone() if row is None: raise ValueError(f"物资不存在: {material_code}") current_qty = row["quantity"] if current_qty < qty: raise ValueError(f"库存不足: 当前 {current_qty}，需要 {qty}") conn.execute( "UPDATE inventory SET quantity = quantity - ?, " "updated_at = datetime('now', 'localtime') " "WHERE material_code = ?", (qty, material_code) ) conn.execute( "INSERT INTO stock_flow " "(doc_no, material_code, flow_type, quantity, " " before_qty, after_qty, operator) " "VALUES (?, ?, 'OUT', ?, ?, ?, ?)", (doc_no, material_code, qty, current_qty, current_qty - qty, operator) )

函数参数含义依次是：连接对象 conn、物资编码、出库数量、关联单据号、操作人。先查当前库存，再检查是否足够，然后执行 UPDATE 扣减，最后插入流水。before_qty 是扣减前查到的值，after_qty 用 current_qty - qty 算出，这样每条流水都能还原当时扣减前和扣减后的库存快照。with conn 的作用是把 SELECT、UPDATE、INSERT 包成一个原子操作，任何一步抛异常，前面所有修改都会回滚。

有人会问：先 SELECT 再 UPDATE，会不会有并发竞争？SQLite 默认事务在写操作发生时获得数据库级写锁，先查询到的 current_qty 在事务未提交前，另一个写事务无法修改同一行；把 SELECT 和 UPDATE 放在同一事务里，就能避免“查询后被人改掉”的窗口。如果以后换到 MySQL，这段逻辑还要改成 SELECT ... FOR UPDATE 或者用乐观锁版本号，逻辑更复杂，但当前 SQLite 场景已经够用。

3.3 可复现的最小 Python 脚本：命令行做入库、出库、盘点核对

数据库结构有了，事务逻辑有了，还需要一个能跑的入口。下面的脚本把入库、出库、查询库存、生成盘点差异四个常用动作做成命令行子命令。这里先给出核心片段，完整建表语句以上一小节为准：

import sqlite3, argparse, json from datetime import datetime def init_db(conn): conn.executescript(""" PRAGMA foreign_keys = ON; CREATE TABLE IF NOT EXISTS inventory ( material_code TEXT PRIMARY KEY, material_name TEXT NOT NULL, spec TEXT, unit TEXT NOT NULL DEFAULT '件', category TEXT, quantity REAL NOT NULL DEFAULT 0 CHECK (quantity >= 0), updated_at TEXT NOT NULL DEFAULT (datetime('now', 'localtime')) ); -- bills 与 stock_flow 建表语句与上文一致，这里省略 """) def make_doc_no(doc_type): return f"{doc_type}-{datetime.now():%Y%m%d%H%M%S}" def main(): parser = argparse.ArgumentParser() parser.add_argument("action", choices=["in", "out", "stock", "check"]) parser.add_argument("--code") parser.add_argument("--name") parser.add_argument("--qty", type=float) parser.add_argument("--operator", default="admin") parser.add_argument("--db", default="warehouse.db") args = parser.parse_args() conn = sqlite3.connect(args.db) conn.row_factory = sqlite3.Row init_db(conn) if args.action == "in": # 不存在则先建档，再入库 conn.execute( "INSERT OR IGNORE INTO inventory " "(material_code, material_name) VALUES (?, ?)", (args.code, args.name) ) with conn: cur = conn.execute( "SELECT quantity FROM inventory WHERE material_code = ?", (args.code,) ) row = cur.fetchone() before = row["quantity"] conn.execute( "UPDATE inventory SET quantity = quantity + ?, " "updated_at = datetime('now', 'localtime') " "WHERE material_code = ?", (args.qty, args.code) ) doc_no = make_doc_no("IN") conn.execute( "INSERT INTO bills (doc_no, doc_type, operator, remark) " "VALUES (?, 'IN', ?, 'from doc')", (doc_no, args.operator) ) conn.execute( "INSERT INTO stock_flow " "(doc_no, material_code, flow_type, quantity, " " before_qty, after_qty, operator) " "VALUES (?, ?, 'IN', ?, ?, ?, ?)", (doc_no, args.code, args.qty, before, before + args.qty, args.operator) ) print(json.dumps({"ok": True, "doc_no": doc_no}, ensure_ascii=False))

实际使用示例是：

python warehouse.py in --code C-2024-001 --name "轴承" --qty 30 --operator 张三 python warehouse.py out --code C-2024-001 --qty 12 --operator 李四 python warehouse.py stock

in 子命令的关键是“先建档再入库”：如果物资编码第一次出现，INSERT OR IGNORE 会先写入一条库存为 0 的基础记录，然后再执行入库更新。这样出库时就不会因为物资不存在而报错。单据号用“类型-年月日时分秒”生成，保证同一秒内多次操作也不会冲突，批量导入时如果发现重复再补后缀。这个脚本没有做界面，但已经具备仓储物资管理系统的最小闭环：入库有据、出库有据、库存可见。

4. 让配置驱动系统启动：JSON 配置与 doc 解析结果打通，少写一半胶水代码

文档解析结果 schema_draft.json 如果只是看一遍就丢到一边，那和第 2 章的价值就断了。更好的做法是把它作为系统的启动配置：字段映射、物资初始清单、单据类型定义都从这份 JSON 加载，代码里不硬编码中文列名。这样下次拿到另一份 .doc，只需改配置文件，不用改业务代码。

4.1 只写一个 loader：把 doc 解析结果作为配置，而不是人肉录表

我常见的设计是单独做一个 loader 模块，负责完成三件事：加载 schema_draft.json、把中文列名映射成英文字段、生成需要预置的库存初始数据。实现不复杂，关键是划定边界，loader 只读配置和清洗数据，不直接操作业务表。如果后续要把 .doc 或 .pdf 也纳入配置读取范围，解析插件只负责把文件转成纯文本或表格结构，字段映射仍然由 loader 负责；这样插件换掉，业务逻辑不受影响。我一直认为，doc 解析这类需求最怕的就是在解析流程里塞业务判断，最后解析代码和业务代码耦合到谁也改不动。

import json def load_schema_meta(path="./schema_draft.json"): with open(path, "r", encoding="utf-8") as f: tables = json.load(f) field_map = { "物资编号": "material_code", "物资名称": "material_name", "规格型号": "spec", "单位": "unit", "库存数量": "quantity", "库位": "location", } row_to_material = [] for table in tables: header = [field_map.get(c, c) for c in table["table_rows"][0]] for raw_row in table["table_rows"][1:]: item = dict(zip(header, raw_row)) if item.get("material_code"): row_to_material.append(item) return row_to_material

这里有个容易被忽视的细节：表格第一行通常不是表头，而是“入库单”这类标题，所以脚本先取 table_rows[0] 当作表头只是示例；真实场景要先跳过合并单元格和空行，确认表头行的位置。另一个细节是 dict(zip(header, raw_row)) 会把长于表头的行自动截掉，短于表头的行自动补不上列，如果 .doc 表格本身残缺，这里会产生字段错位，所以 loader 输出后必须配套一条校验命令，打印每个物料的字段缺失情况。

配置驱动的优点是把容易变的东西集中到一个地方。仓储物资管理系统里最容易变的配置只有几项，列出来反而比堆抽象配置更实用。库文件路径默认指向 warehouse.db，迁移时直接改路径即可；单据号前缀要和现场习惯一致，有的仓库叫 IN/OUT，有的叫 RK/CK，统一成字符前缀后流水查询更直观；负库存开关建议默认关闭，也就是数据库 CHECK 约束保持生效；时区设置决定 created_at 的默认值，SQLite 的 datetime('now') 返回 UTC，localtime 参数指定本地时间，这在跨时区服务器上是很常见的踩坑点。

一个反直觉的参数是单据号长度。从 .doc 时代的纸面单据迁移过来时，现场往往有很长的完整单据号，比如“RK-2024-01-15-003”。如果系统自动生成的号码过短，打印出来和旧单据混排会非常奇怪。我一般会把自动生成部分控制在 18 位以内，并允许外部单据号直接写入，系统只做唯一性校验，不做强制改号。

4.2 起步配置的 4 个必调参数：库文件路径、单据号前缀、负库存开关、时区

配置驱动的优点是把容易变的东西集中到一个地方。仓储物资管理系统里最容易变的配置只有几项，列出来反而比堆抽象配置更实用。库文件路径默认指向 warehouse.db，迁移时直接改路径即可；单据号前缀要和现场习惯一致，有的仓库叫 IN/OUT，有的叫 RK/CK，统一成字符前缀后流水查询更直观；负库存开关建议默认关闭，也就是数据库 CHECK 约束保持生效；时区设置决定 created_at 的默认值，SQLite 的 datetime('now') 返回 UTC，localtime 参数指定本地时间，这在跨时区服务器上是很常见的踩坑点。

一个反直觉的参数是单据号长度。从 .doc 时代的纸面单据迁移过来时，现场往往有很长的完整单据号，比如“RK-2024-01-15-003”。如果系统自动生成的号码过短，打印出来和旧单据混排会非常奇怪。我一般会把自动生成部分控制在 18 位以内，并允许外部单据号直接写入，系统只做唯一性校验，不做强制改号。

4.3 上线前的验证清单：用一张核对表确保字段、流水与约束到位

配置改完之后，最怕的就是“看起来能跑，一盘点就错”。下面这张核对表是我每次上线前都会过一遍的清单，适用于 50 种物资以下的小型仓库，也适合中型仓库做首轮验收：

这张表的价值在于把验收从“开发说没问题”变成“用事实核对”。每一条都对应一个可重复操作，不依赖拍胸脯。如果哪一步没过，不要继续往下测，先回头改 loader 或建表语句，否则后面所有验证都被污染。我自己通常把这张表贴在项目目录的 README 里，每次接手别人的系统也先按这个顺序过一遍。

5. 仓储物资管理系统的 5 个高频踩坑点：现象、原因与解法

仓储系统上线后的问题，大多数不是算法复杂，而是在看似不起眼的数据细节上翻车。下面五条是我在 .doc 迁移、Excel 记账转换、多人协作过程中反复撞过的墙，每一条都按“现象、原因、解决”写清楚，方便对照排查。

5.1 坑一：合并单元格导入后错位，账面数对不上实物

现象：第 2 章导出的 JSON 里，一个“规格型号”列的值出现在物资名称列，或者整列数据往后错了一位；按错误数据初始化库存后，A 物资的库存被记到 B 物资名下。

原因：Word 表格里横向或纵向合并单元格后，python-docx 的 row.cells 会把同一个单元格对象重复返回一次或多次，导致同一行的 cells 数量多于实际列数，解析时一视同仁地展平就错位了。这属于 .doc 解析里最常见的结构坑，和表格样式强相关，没有万能解析器。

解决：解析时先对每行做去重，相同 cell 对象只保留第一个；如果整张表在某个位置固定出现多列重复，用一个配置项记录该表的合并样式，解析时按列偏移补齐。我在实际项目里的做法是把每张表的表头单独人工确认一次，然后把“表头列数”作为参数传给解析函数，解析后立即校验每行列数是否等于表头列数，不等就报错并跳过该行，而不是硬着头皮写入数据库。宁可少导一行，也不能导错一行。

5.2 坑二：出库顺序颠倒导致负库存，月底盘点才爆雷

现象：账面出现负数，或者在盘点时发现某个物资的流水总和与库存完全不匹配，往前翻才发现某天的出库单比入库单更早。

原因：手工录入时先录出库后补入库单，或批量导入时按 Excel 行顺序执行，没有按时间排序；系统又没有负库存拦截，负值被写进了库存表。负库存出现后不会主动报错，业务继续跑，月底才被发现。

解决：两个层面同时处理。第一，inventory 表保留 CHECK (quantity >= 0) 约束，从数据库层拦截负数；第二，批量导入历史数据前，对同一物资按单据日期升序排列，先处理入库再处理出库。更稳的办法是不直接用“最终库存”初始化，而是把历史单据全部导入 stock_flow，再让系统从零累加生成 inventory，这样顺序错了系统立刻能查出来。后一种做法多写一段累加脚本，但能省掉后面无数对账时间。

5.3 坑三：单位只记“件”不记换算，批次混用翻车

现象：同一物资在不同批次里分别以“箱”和“件”入库，出库时统一按“件”扣，月底一算库存少了，或者负得莫名其妙。

原因：库存表里只有一个 unit 字段，而业务单据里两种单位混用，程序无法识别 1 箱等于 20 件，直接把 1 和 20 相加。问题根子在于数据模型里没有“基本单位”和“换算比例”的概念。

解决：第一版最低要求是强制统一单位，所有入库单据在写入前必须换算成同一单位并记录换算比例。给 inventory 增加一个 base_unit（基本单位）字段，同时在物料表旁边建一张 unit_conversion 表，存 material_code、from_unit、to_unit、rate。换算是业务逻辑，不是字段凭空能解决的；单位换算表要有录入入口，而不是靠程序员改配置。宁可少做功能，也不能让同一个物料有两种并存且未换算的单位。我在第 3 章的表结构里没有放换算表，因为第一版线上跑的时候还没遇到混用，第二版就被这个坑打了一次，现在都提前把单位列全。

5.4 坑四：把 .doc 当数据库直接改，版本一多就失控

现象：原始 .doc 一直在被人手工增删行，改完后再导入系统，数量对不上；更有甚者，直接把 .doc 里某一行的库存数改了，没走任何单据流程，系统却完全不知道。

原因：习惯了 Word 表格的同事把 .doc 当成了权威数据源，系统反而成了“只读报表”。两份数据源并存，又没有同步机制，最终必然以某一方为准，而另一方的修改全部丢失。这是从文档转系统最常见的组织级问题，不是技术能单独解决的。

解决：明确 .doc 只是历史快照，上线后系统数据库才是唯一权威数据源。把“从 .doc 导入”做成一次性初始化动作，上线后立即锁定文档权限；后续所有变更一律走入库单和出库单。如果现场确实需要手工调整，必须走 CHECK 盘点单并记录差异原因。这套规则要靠流程约束，技术能做的只是把 CHECK 类型的单据做出来，让每一次手工调整都有凭证。我还会在系统里留一个“导入时间戳”，超过导入时间之后的 .doc 修改一律不在系统里体现，避免混乱。

5.5 坑五：单机 Excel 记账还好，一上多人并发就翻车

现象：两个仓管员同时在系统里操作同一个物资，A 先查询库存为 10 件，B 也查询库存为 10 件，A 出库 8 件，B 再出库 5 件，最后系统只扣了 5 件或直接报错。

原因：没有锁和事务，或者代码里先查后改那两步没放在同一个事务里；SQLite 单写并发本身能保证不写坏文件，但应用层逻辑把多个步骤拆开执行，就制造了过期读。这个问题在 Excel 时代不存在是因为 Excel 文件经常被整体锁住，换成数据库后反而因为连接隔离暴露出来。

解决：按第 3.2 节的方式把所有“查库存+扣库存+写流水”放进一个事务。对于单仓几十个并发的小系统，SQLite 已经足够；如果后续并发超过 100 或需要跨仓库操作，再迁到 MySQL，并把这套事务逻辑改为行锁或乐观锁。不要一开始就追求分布式锁，那在 10 个人的仓库里是过度设计。上线后用两个客户端同时操作同一个物资做压测，比任何理论分析都更能说明问题。

6. 收尾技巧：每天自动导出一份对账报告，同事也能照做

系统跑起来之后，最容易被忽视的就是“让数据自己说话”。我习惯在最后加一个每日自检脚本，定时扫描三张表，输出一份对账报告。报告不追求复杂，只检查四件事：所有物资库存是否非负；流水总笔数与前一日相比是否异常；每张已关闭单据是否都有对应流水；盘点差异表中是否有三天以上未处理的记录。

def daily_report(conn, date_str): rows = conn.execute(""" SELECT material_code, material_name, quantity FROM inventory WHERE quantity < 0 """).fetchall() flows_count = conn.execute( "SELECT COUNT(*) AS c FROM stock_flow WHERE created_at LIKE ?", (date_str + "%",) ).fetchone()["c"] report_lines = [ f"日期: {date_str}", f"当日流水笔数: {flows_count}", f"负库存物资数: {len(rows)}", ] for r in rows[:10]: report_lines.append(f" {r['material_code']} {r['material_name']}: {r['quantity']}") return "\n".join(report_lines)

这个函数胜在简单，date_str 参数传入“2025-04-10”这样的日期前缀，created_at LIKE 匹配当天所有流水。负库存扫描是个很好的健康指标，出现过一次就要去查流水顺序和手工调整，而不是简单把它改成 0。报告可以用 txt 输出，也可以用 pandas 转成表格再另存为 pdf，看现场习惯。

我的习惯是把它做成定时任务，每天早上九点把报告写到团队共享目录，同事打开就知道前一天有没有异常。真正上手后会发现，一套仓储物资管理系统最值钱的部分不是界面好不好看，而是异常出现时能不能在十分钟内定位到单据和操作人。tdsql 这类从文档解析起步的配置读取方向也一样：先让数据可见，再谈自动化。我希望这份拆解能帮你从 .doc 顺利走到系统上线，少踩几个我已经替你踩过的坑，希望帮到你。

本文还有配套的精品资源，点击获取