中小企业做进销存,最常见的困境是:用 Excel 手记容易出错,上商业 ERP 又贵又重,定制开发周期长到业务等不起。DBErp 作为一套开源的进销存系统,围绕采购、销售、库存、结算、报表这几条主线构建,v3.0.0-rc.2 版本继续打磨了系统更新能力和库存链路,离正式版越来越近。如果你正在为小企业找一套可独立部署、可二次扩展的方案,值得关注一下当前版本的成熟度。
业务主线覆盖了什么
DBErp 的功能模块不是堆砌,而是沿着"货从哪里来、到哪里去、钱怎么算"这条链路设计的:
- 商品资料:SKU 管理、分类、规格、单位换算,是后续所有业务的数据基础。
- 仓库库存:多仓库、入库出库调拨、库存预警。rc.2 重点优化了库存相关链路,意味着入库单→库存增量、出库单→库存减量之间的联动更可靠。
- 采购管理:采购订单→采购入库→采购退货,完整闭环。
- 销售管理:销售订单→销售出库→销售退货,与采购对称。
- 往来结算:供应商应付、客户应收,对账核销。
- 报表查询:进销存汇总、利润分析、库存周转等。
这套设计的好处是:每个模块独立可用,但数据之间有因果关联。比如一张采购入库单审核后,库存自动增加、应付自动生成,不需要人工再填一遍。
rc.2 在打磨什么
作为正式版前的 RC,rc.2 的重心不在新功能,而在让已有功能更稳:
- 系统更新能力:开源项目最怕升级断档。rc.2 改进了版本升级的迁移机制,降低从 v2 跳到 v3 的数据风险。对于已经在用旧版本的企业,这是决定能不能跟上去的关键。
- 基础业务体验:表单交互、审批流转、单据打印这些日常高频操作,细节打磨后减少了操作摩擦。
- 库存链路:入库、出库、调拨、盘点之间的数量联动和状态一致性,是进销存系统最容易出 bug 的地方。rc.2 在这块加强,说明开发团队在啃硬骨头。
独立部署实践
DBErp 支持独立部署,下面给出一个基于 Docker Compose 的最小部署方案。注意:具体镜像和配置参数需以项目官方文档为准,以下示例基于典型的 LAMP/LNMP 架构进销存系统结构,可按实际项目调整。
# docker-compose.yml — DBErp 最小部署示例
# 请根据项目官方文档调整镜像名、端口和数据卷路径
version: "3.8"
services:
dberp-db:
image: mysql:8.0
restart: unless-stopped
environment:
MYSQL_ROOT_PASSWORD: "ChangeMeRootPwd2024"
MYSQL_DATABASE: dberp
MYSQL_USER: dberp
MYSQL_PASSWORD: "ChangeMeDbPwd2024"
volumes:
- dberp-db-data:/var/lib/mysql
- ./init-db:/docker-entrypoint-initdb.d # 初始化 SQL 脚本放这里
ports:
- "127.0.0.1:3306:3306" # 仅本地访问,生产环境不要暴露
dberp-app:
image: dberp/dberp:3.0.0-rc2 # 替换为官方发布的镜像名
restart: unless-stopped
depends_on:
- dberp-db
environment:
DB_HOST: dberp-db
DB_PORT: 3306
DB_NAME: dberp
DB_USER: dberp
DB_PASS: "ChangeMeDbPwd2024"
APP_ADMIN_EMAIL: admin@example.com
APP_ADMIN_PASSWORD: "ChangeMeAdminPwd2024"
volumes:
- dberp-app-data:/var/www/html/upload # 上传文件持久化
ports:
- "8080:80"
volumes:
dberp-db-data:
dberp-app-data:
部署步骤:
# 1. 克隆或下载项目配置
mkdir dberp-deploy && cd dberp-deploy
# 将上面的 docker-compose.yml 保存到当前目录
# 2. 如果项目提供了初始化 SQL,放到 init-db/ 目录
mkdir -p init-db
# cp /path/to/dberp-init.sql init-db/
# 3. 启动
docker compose up -d
# 4. 检查状态
docker compose ps
docker compose logs dberp-app --tail 30
# 5. 访问
# 浏览器打开 http://localhost:8080
# 用 APP_ADMIN_EMAIL / APP_ADMIN_PASSWORD 登录
部署前务必改掉所有 ChangeMe 占位密码,生产环境还应加上 HTTPS 反向代理(Nginx/Caddy)和数据库定期备份。
二次开发:从哪里入手
中小企业用进销存,几乎一定会遇到"标准功能不够,需要加字段或加流程"的情况。DBErp 作为开源项目,二次开发是它的核心卖点之一。几个常见的切入点:
加一个自定义商品属性
假设你的企业需要给商品加"保质期天数"字段,用于临期预警:
-- 在商品表增加字段(具体表名以项目实际 Schema 为准)
ALTER TABLE dberp_goods ADD COLUMN shelf_life_days INT DEFAULT NULL COMMENT '保质期天数';
-- 创建临期预警视图
CREATE OR REPLACE VIEW v_goods_near_expiry AS
SELECT
g.goods_id,
g.goods_name,
g.shelf_life_days,
i.in_stock_date,
DATEDIFF(CURDATE(), i.in_stock_date) AS days_in_stock,
g.shelf_life_days - DATEDIFF(CURDATE(), i.in_stock_date) AS days_remaining
FROM dberp_goods g
JOIN dberp_inventory i ON g.goods_id = i.goods_id
WHERE g.shelf_life_days IS NOT NULL
AND (g.shelf_life_days - DATEDIFF(CURDATE(), i.in_stock_date)) <= 30;
后端代码层面,需要在对应的 Model 和 Controller 中同步增加字段读写逻辑,前端表单也要加上输入框。这种改动在开源项目中属于最轻量的二次开发——加字段、加视图、加表单控件,不改变核心流程。
写一个库存预警推送脚本
#!/usr/bin/env python3
"""库存预警推送 — 定时检查低库存商品,推送到企业微信群"""
import requests
import pymysql
import os
from datetime import datetime
DB_CONFIG = {
"host": os.getenv("DB_HOST", "127.0.0.1"),
"port": int(os.getenv("DB_PORT", "3306")),
"user": os.getenv("DB_USER", "dberp"),
"password": os.getenv("DB_PASS", "ChangeMeDbPwd2024"),
"database": os.getenv("DB_NAME", "dberp"),
}
WECHAT_WEBHOOK = os.getenv("WECHAT_WEBHOOK_URL", "")
ALERT_THRESHOLD = int(os.getenv("STOCK_ALERT_THRESHOLD", "10")) # 默认低于 10 件预警
def check_low_stock():
conn = pymysql.connect(**DB_CONFIG)
try:
with conn.cursor() as cur:
cur.execute(
"""
SELECT g.goods_name, i.actual_stock, i.warehouse_name
FROM dberp_goods g
JOIN dberp_inventory i ON g.goods_id = i.goods_id
WHERE i.actual_stock <= %s
ORDER BY i.actual_stock ASC
""",
(ALERT_THRESHOLD,),
)
return cur.fetchall()
finally:
conn.close()
def send_wechat_alert(items):
if not WECHAT_WEBHOOK:
print("未配置 WECHAT_WEBHOOK_URL,仅打印预警:")
for name, stock, warehouse in items:
print(f" [{warehouse}] {name} — 库存 {stock} 件")
return
lines = [f"**库存预警** ({datetime.now().strftime('%Y-%m-%d %H:%M')})"]
for name, stock, warehouse in items:
lines.append(f"- [{warehouse}] **{name}** — 仅剩 {stock} 件")
payload = {
"msgtype": "markdown",
"markdown": {"content": "\n".join(lines)},
}
resp = requests.post(WECHAT_WEBHOOK, json=payload, timeout=10)
print(f"推送结果: {resp.status_code}")
if __name__ == "__main__":
low_items = check_low_stock()
if low_items:
send_wechat_alert(low_items)
else:
print("当前无低库存商品")
用 cron 或 Kubernetes CronJob 每小时跑一次,就能把库存预警从"人盯报表"变成"系统主动推消息"。
采纳前需要权衡的几个点
| 维度 | 判断 |
|---|---|
| 版本成熟度 | rc.2 是 RC 版本,核心功能可用但升级路径和数据迁移还在打磨,生产环境建议先在测试环境完整跑一遍采购→入库→销售→出库→结算闭环 |
| 二次开发成本 | 开源意味着可以改,但也意味着改完要自己维护。评估团队是否有 PHP/对应框架的维护能力 |
| 数据安全 | 独立部署数据在自己服务器上,不经过第三方 SaaS,合规敏感行业(医药、食品)更安心;但备份和灾备要自己做 |
| 社区活跃度 | 关注项目 Issue 区和更新频率,判断遇到问题时能不能找到参考或得到响应 |
上手清单
- 在测试环境用 Docker Compose 跑起 rc.2,走完一条完整的采购入库→销售出库→对账结算流程。
- 对比当前 Excel 或旧系统中的字段,列出需要新增或调整的属性,评估二次开发工作量。
- 配置数据库自动备份(
mysqldump+ cron 或 Docker volume 快照)。 - 如果决定上线,加 Nginx 反向代理 + HTTPS,关闭数据库端口外部暴露。
- 持续关注正式版发布节奏,rc.2 到 v3.0.0 正式版之间的升级说明要仔细读——这是数据最容易出问题的窗口期。
进销存系统不是选最炫的,而是选最稳的、能跟着业务长的。DBErp 的开源 + 独立部署路线,给了中小企业一个"先小跑、后加速"的选项。