为 11 家餐饮门店设计并交付订货与库存 ERPv1，覆盖 300+ SKU 和 4000+ 订单，系统持续运行两年多；后续重构为 ERPv3 演示版本。
围绕 11 家餐饮门店、300+ SKU 的订货与仓库库存流程，独立负责需求、产品、全栈开发、部署和运维；累计处理 4000+ 订单，系统持续运行两年多。
任职北京惠众恒瑞商贸有限公司期间，为 11 家餐饮门店和 300+ SKU 的订货与库存业务设计、开发、部署并运维 ERPv1；系统累计处理 4000+ 订单并持续运行两年多。后续基于该项目经验重构 ERPv3 公开演示版本；演示环境仅使用模拟数据，不含任何真实经营信息。
模拟数据工作台：集中呈现门店订货单、仓库库存预警与常用业务入口。
餐饮门店需要持续向仓库订货，仓库据此完成出库并维护库存。只依赖零散表格时，门店需求、订货单、出入库记录和库存变化容易断开。
围绕门店订货单、仓库库存、入库、出库和操作记录建立系统对象，让每次门店订货都能对应仓库动作与库存变化。
ERPv1 已用于 11 家餐饮门店、300+ SKU 的真实订货与库存流程，累计处理 4000+ 订单并持续运行两年多；我负责需求、产品设计、开发、部署和后续维护。公开的 ERPv3 是使用模拟数据重构的演示版本。
管理餐饮门店向仓库提交的订货单及其流转状态。
维护仓库商品、库存数量和库存变化记录。
把仓库入库、向门店出库和库存变动绑定到订货流程。
保留关键操作记录，方便回看和纠错。
管理部署、账号、运行维护与持续迭代，让业务系统能够长期使用。
选择：优先打通商品、门店订货单、仓库入库、出库和库存变化。
理由：门店能否准确订货、仓库能否按单出库并保持库存可信，是系统首先要解决的业务问题。
选择：通过 admin / Admin@123456 暴露可访问演示入口。
理由：让招聘方能核验真实系统形态；演示环境仅包含模拟数据，不承载真实经营信息。
选择：由同一负责人贯通需求、数据模型、前后端实现、部署与运维。
理由：资源有限的企业数字化项目更需要控制范围，让产品方案与实际可交付能力保持一致。
