重复导入不能重复增加年度累计
- 1读取月度金额
- 2更新月快照
- 3计算新旧差额
- 4调整年度累计
第一次导入月份时增加年度值；同月重导只调整差额；清零月份同步扣减。旧模板保留年度汇总列，但存在月度金额时以月度数据计算为准，模板和中越文提示同时更新。
Skip to content
跳到项目内容商品管理与渠道映射01 / 02 应用订单、渠道订单与导入数据进入不同业务模块；SKU 映射和来源路由决定聚水潭履约目标。Haravan 单店已接入生产，多站沿用同一底座扩展。
项目速览
业务背景
电商业务既需要面向消费者的下单体验，也需要后台对订单、库存和外部履约系统的管理。项目覆盖移动端商城与业务后台，并处理历史订单导入、Haravan / 聚水潭集成和越南时区下的订单时间语义；Haravan 店铺订单已在生产环境自动进入聚水潭履约。
负责范围
- 移动端商城与管理后台
- 订单报价与金额规则
- 历史订单导入
- 渠道订单、SKU 映射与履约路由
- 集成中心与单笔补推
月度快照
重复导入语义
新增、覆盖和清零分别调整年度差额，兼容既有模板。
900 项
后端测试
渠道接入与自动映射上线时的后端全量测试；管理后台 223 项，数据库迁移 145 个版本。
中 / 越
跨区域业务
导入提示、金额口径与订单时区配套处理。
01
核心业务
电商系统包含 Flutter 移动商城、Java / Spring Boot 业务后端、管理后台和聚水潭履约适配。报价、订单、SKU 映射、库存与来源渠道共同决定订单最终如何进入履约系统。
项目既处理在线交易，也处理历史线下进货数据。月度导入会影响年度累计，越南业务时间会进入外部平台字段；这些数据口径如果只在页面上修正，会让账务、履约和报表继续分歧。
- 01报价与订单
- 优惠和金额门槛围绕最终应付金额计算，报价与创建订单使用同一口径。
- 02SKU 与履约
- 来源账号、外部 SKU、内部商品和目标履约 SKU 通过映射与来源路由关联。
- 03数据导入与累计
- 月度快照更新年度累计，重复导入、改值和清零都需要反映正确差额。
02
技术栈
- 客户端
- FlutterAndroid
- 后端
- JavaSpring Boot
- 数据
- MySQL隔离 H2 演示环境
- 业务集成
- Haravan聚水潭订单 / 库存适配
03
系统架构与部署
移动端与管理端
Flutter / Web 后台消费者下单与商品、导入、渠道配置管理分开。
核心服务
Java / Spring Boot / MySQL报价、订单、月度基线、SKU 映射和履约路由保存为业务数据。
外部系统
聚水潭 Adapter / 多平台账号模型查询库存、推送订单、取消及物流状态；Haravan 店铺订单轮询拉取、库存定时同步、订单自动推送 ERP。
集成中心
平台与 ERP 账号 / 渠道订单集中管理平台账号、ERP 账号和渠道订单，单笔订单可精确补推。
04
核心业务链路
订单来源决定履约账号和 SKU
- 1来源账号 / SKU
- 2专属路由优先
- 3通用路由回退
- 4聚水潭订单
订单明细保留来源平台、来源 SKU、目标账号和目标 SKU。路由优先使用来源站点专属配置，再回退通用配置，避免每新增一个渠道就复制整套履约逻辑。
05
关键机制与取舍
01月快照与年度增量的兼容更新
- 约束
- 整文件重复累加会把历史金额算两次，直接用本次文件覆盖全年又会丢掉数据库已有月份。
- 做法
- 以月份作为快照单元覆盖数据，年度累计按新旧差额增减；兼容旧模板，同时更新金额解释和导入提示。验证新增月份、同月修改与清零，测试后恢复业务数据。
- 效果
- 历史导入既支持补月，也支持纠错，幂等语义明确到业务数据粒度。
02报价和下单共享应付金额口径
- 约束
- 购物车门槛按原价、订单按优惠后金额校验，会让前台允许提交的订单被后端拒绝。
- 做法
- 门槛改为使用 payableAmount，与订单创建校验保持一致；金额规则回归同时覆盖报价服务与管理说明。
- 效果
- 消费者看到的支付资格与后端真正接受的金额条件一致。
03业务当地时间与外部平台字段分开
- 约束
- 跨区域服务器和外部系统对日期字段的解释不同，会让同一订单在后台与履约端显示为不同一天。
- 做法
- 核对订单业务时区和外部请求字段转换，将越南当地时间作为订单业务语义，再按接口合同映射输出，不自动重写已经推送的历史订单。
- 效果
- 修正新订单的时间表达，同时保留历史履约记录的业务边界。
04渠道订单先落到 ERP 账号，再到店铺，并冻结在订单上
- 约束
- 同一渠道店铺可能对应不同 ERP 账号和店铺，路由配置后续还会调整；如果履约时才实时查路由，已推送订单会因配置变化出现前后不一致。
- 做法
- 订单按“渠道 → ERP 账号 → ERP 店铺”解析履约目标，结果冻结在订单快照里；同编码 SKU 自动建立映射，异常订单可按单笔精确补推。
- 效果
- 生产店铺的 25 个 SKU 全部完成映射，其中 23 个由同编码自动映射；真实渠道订单已进入生产聚水潭并推送成功。
06
AI 协作开发
开发在 Cursor Agent 中进行，仓库的 AI 开发说明规定了测试范围、测试隔离方式，以及最后回复必须包含的内容。
- 仓库规则
成功、失败与权限都要测
每个新功能都要覆盖成功、失败和权限或状态边界；订单、支付、库存等核心流程必须有回归测试，无法自动化的写明手工步骤。
- 测试隔离
测试打不到真实 ERP
测试脚本清空 ERP 密钥并把地址指向不可达的本地端口；远程、真实 ERP 和发布类任务即使被误标为自动也会被拒绝。
- 交付要求
列出实际运行的命令
分层测试脚本提供 fast、verify、core、full 和按改动范围执行的入口，Agent 的最后回复必须列出实际运行过的命令。
长时间运行的服务放在持久终端里，避免随 Agent 子进程一起退出。
07
阶段成果
- 历史导入、时间字段修正与 Haravan 单店接入完成生产上线，移动端、后台和履约接口形成业务协同。
- 多站扩展复用账号、SKU 和路由底座；发货状态回写、组合商品库存与多仓仍是明确的边界。
继续浏览
别急，先让缓存热一下。