重复导入不能重复增加年度累计
读取月度金额 → 更新月快照 → 计算新旧差额 → 调整年度累计
第一次导入月份时增加年度值；同月重导只调整差额；清零月份同步扣减。旧模板保留年度汇总列，但存在月度金额时以月度数据计算为准，模板和中越文提示同时更新。
Appearance
Skip to content
跳到项目内容商品管理与渠道映射01 / 02 应用订单与导入数据进入不同业务模块；SKU 映射和来源路由决定聚水潭履约目标。Haravan 多站接入属于基于现有底座的扩展设计。
商业系统/阶段上线
多渠道电商业务系统
订单、库存与履约的跨系统协同
01
核心业务
电商系统包含 Flutter 移动商城、Java / Spring Boot 业务后端、管理后台和聚水潭履约适配。报价、订单、SKU 映射、库存与来源渠道共同决定订单最终如何进入履约系统。
项目既处理在线交易，也处理历史线下进货数据。月度导入会影响年度累计，越南业务时间会进入外部平台字段；这些数据口径如果只在页面上修正，会让账务、履约和报表继续分歧。
- 报价与订单
- 优惠和金额门槛围绕最终应付金额计算，报价与创建订单使用同一口径。
- SKU 与履约
- 来源账号、外部 SKU、内部商品和目标履约 SKU 通过映射与来源路由关联。
- 数据导入与累计
- 月度快照更新年度累计，重复导入、改值和清零都需要反映正确差额。
02
技术栈
- 客户端
- Flutter · Android
- 后端
- Java · Spring Boot
- 数据
- MySQL · 隔离 H2 演示环境
- 业务集成
- Haravan · 聚水潭 · 订单 / 库存适配
03
系统架构与部署
移动端与管理端
Flutter / Web 后台消费者下单与商品、导入、渠道配置管理分开。
核心服务
Java / Spring Boot / MySQL报价、订单、月度基线、SKU 映射和履约路由保存为业务数据。
外部系统
聚水潭 Adapter / 多平台账号模型查询库存、推送订单、取消及物流状态；Haravan 扩展沿账号与映射模型设计。
04
核心业务链路
订单来源决定履约账号和 SKU
来源账号 / SKU → 专属路由优先 → 通用路由回退 → 聚水潭订单
订单明细保留来源平台、来源 SKU、目标账号和目标 SKU。路由优先使用来源站点专属配置，再回退通用配置，避免每新增一个渠道就复制整套履约逻辑。
05
关键机制与取舍
月快照与年度增量的兼容更新
整文件重复累加会把历史金额算两次，直接用本次文件覆盖全年又会丢掉数据库已有月份。
以月份作为快照单元覆盖数据，年度累计按新旧差额增减；兼容旧模板，同时更新金额解释和导入提示。验证新增月份、同月修改与清零，测试后恢复业务数据。
历史导入既支持补月，也支持纠错，幂等语义明确到业务数据粒度。
报价和下单共享应付金额口径
购物车门槛按原价、订单按优惠后金额校验，会让前台允许提交的订单被后端拒绝。
门槛改为使用 payableAmount，与订单创建校验保持一致；金额规则回归同时覆盖报价服务与管理说明。
消费者看到的支付资格与后端真正接受的金额条件一致。
业务当地时间与外部平台字段分开
跨区域服务器和外部系统对日期字段的解释不同，会让同一订单在后台与履约端显示为不同一天。
核对订单业务时区和外部请求字段转换，将越南当地时间作为订单业务语义，再按接口合同映射输出，不自动重写已经推送的历史订单。
修正新订单的时间表达，同时保留历史履约记录的业务边界。
06
实践成果与验证
月度快照
重复导入语义
新增、覆盖和清零分别调整年度差额，兼容既有模板。
来源路由
渠道扩展底座
站点专属配置优先，再回退通用履约目标。
中 / 越
跨区域业务
导入提示、金额口径与订单时区配套处理。
- 历史导入与时间字段修正完成阶段上线，移动端、后台和履约接口形成业务协同。
- 多站接入方案复用账号、SKU 和路由底座，已实现能力与扩展设计在案例中分别说明。
继续浏览
别急，先让缓存热一下。