KANGBITE · SMART NUTRITION SETTLEMENT

一卡通不再逐个“硬接”
而是接入同一套标准能力

营养结算系统统一负责订单、营养规则、账务、异常与对账；每家一卡通只需交付一个可验收的适配器。

我们要建设的是什么

不是一个绑定某家厂商的消费功能，而是一套可持续复制的 Provider Adapter 平台。新项目增加供应商适配器，不再改写营养订单主链路。

统一订单

所有餐别、营养规则、金额、补贴和用户订单由标准系统生成。

统一交易

每笔交易都有供应商、设备、扣款状态、上传状态和可追溯凭据。

统一验收

每家供应商都按同一能力清单、异常场景和上线门禁验证。

三类接入，一套内核

类型典型厂商能力系统如何接入实时营养结算
在线 APIREST / SOAP 下单、查单、冲正我方服务端 Provider Adapter可以
现场设备Windows DLL、读卡器、PSAM、实体卡厂商/客户 Windows Agent + 我方标准接口可以
流水同步厂商导出或回推消费流水数据同步 Adapter仅事后统计

Change T5.0 的正确位置

Change 是“现场设备型适配器”
它操作实体卡、读卡器与 PSAM；营养结算系统不直接加载 DLL，也不承担 Windows 运维。
营养结算系统
订单、金额、营养规则
→
标准 Agent 接口
任务、回执、对账、告警
→
客户/厂商 Windows Agent
Change DLL、读卡器、PSAM

一次结算如何完成

  1. 营养结算系统创建唯一订单，明确金额和钱包。
  2. 现场 Agent 主动拉取本设备任务，不开放 Windows 入站端口。
  3. Agent 读卡并调用厂商能力完成扣卡。
  4. Agent 回传扣款凭据；系统进入“已扣卡、待上传”状态。
  5. Agent 上传一卡通中心并回传结果；系统完成结算或转入异常处理。
关键规则：实体卡已扣但中心未上传时，不能再次扣款。系统只允许重传同一笔上传记录或进入人工处理。

责任清晰，项目才能复制

我们负责客户/一卡通厂商负责
订单与营养规则、标准接口、交易状态机、对账、后台异常处理、统一验收。Windows Agent、Change DLL、读卡器/PSAM、设备驱动、本地断网队列、厂商上传与退款能力。
不保存厂商注册码、PSAM 密钥或完整卡号。不将 DLL、注册码和硬件控制暴露给浏览器或公网。

Change 首轮接入前必须确认

32 位 Windows读卡器 + PSAM主/补钱包断网重传灰色记录恢复退款/冲正NFC 能力

T5.0 包已确认是 32 位 Windows DLL 套件。资料提及 NFC 扩展 DLL，但当前包未包含它；退款/冲正能力也必须由厂商实机证明后才能纳入合同和上线范围。

最终得到的产品能力

对客户

不换原有一卡通，也能接入营养结算与食堂订单。

对交付

每个厂商按同一张能力表、同一套验收用例进入项目。

对产品

一次建设 Provider 平台，后续接入不再侵入订单核心。