业务和功能介绍
1. 立项背景和目标
公司销售环节已使用纷享销客 CRM 管理客户、销售订单与回款流程，但财务、库存、生产环节仍依赖 K/3 ERP（SQL Server 2008 R2，AIS20130806192009 账套）。两套系统长期互不相通，订单需要人工二次录入，客户变更也无法及时回流到 ERP，导致数据孤岛、人力浪费以及业务-财务对账滞后等问题。本项目旨在构建一个轻量级中间对接服务（ConnectDemo），以 K/3 为主数据底座，将纷享销客的客户主数据与销售订单自动同步到 K/3，支撑业务一体化运营。
2. 软件功能、核心功能模块介绍
本服务围绕「K/3 数据查询、纷享→K/3 客户/订单同步、辅助工具、定时任务」四大模块建设，共 25+ 个 REST 接口：
K/3 业务数据查询：封装物料（ICItem）、库存（ICInventory）、销售订单（SEOrder）、应收单（ICSale）、收款单（ReceiveBill）、销售发票（ICSale2）六大实体的列表与数量接口，按日期范围分页查询。
客户主数据同步：调用纷享 Open API（/cgi/crm/v2/data/query）按 life_status=normal + k3_sync_fields_last_modify__c >= 1小时前 增量拉取客户，结合 Address/Contact 对象补全地址与联系人，写入 K/3 的 t_Item、t_Organization 表。
销售订单同步：/k3/sync-seorder 是核心，按 FBillNo + FHeadSelfS0170 来源标识判定新建/修改，调用 GetICMaxNum 存储过程获取 FInterID，通过 t_billcodeby 生成 XSDD15+yyyymmdd+流水号 形式的单据编号，写入 SEOrder 主表、明细表后执行 p_UpdateBillRelateData 重建关联。
辅助工具：地址智能解析（/util/parse-address-info）将「姓名+电话+省市区+详细地址」一锅端的混合文本拆分为结构化字段；客户档案修订接口（/account/update-account-number）支持必要时调整 K/3 客户编码。
3. 业务流程、功能路径描述
被动同步（客户）：纷享销客工作流回调 GET /fxapi/sync-accounts → 服务 60 秒后异步拉取最新客户 → 写入 K/3。主动同步（客户）：APScheduler 每小时执行 sync_accounts_from_fxiaoke_to_k3 → 调用本地 accounts_by_filters → 拉取增量客户 → 写入 K/3。
订单同步：纷享订单审批完成后回调 POST /k3/sync-seorder → 服务按
公司销售环节已使用纷享销客 CRM 管理客户、销售订单与回款流程，但财务、库存、生产环节仍依赖 K/3 ERP（SQL Server 2008 R2，AIS20130806192009 账套）。两套系统长期互不相通，订单需要人工二次录入，客户变更也无法及时回流到 ERP，导致数据孤岛、人力浪费以及业务-财务对账滞后等问题。本项目旨在构建一个轻量级中间对接服务（ConnectDemo），以 K/3 为主数据底座，将纷享销客的客户主数据与销售订单自动同步到 K/3，支撑业务一体化运营。
2. 软件功能、核心功能模块介绍
本服务围绕「K/3 数据查询、纷享→K/3 客户/订单同步、辅助工具、定时任务」四大模块建设，共 25+ 个 REST 接口：
K/3 业务数据查询：封装物料（ICItem）、库存（ICInventory）、销售订单（SEOrder）、应收单（ICSale）、收款单（ReceiveBill）、销售发票（ICSale2）六大实体的列表与数量接口，按日期范围分页查询。
客户主数据同步：调用纷享 Open API（/cgi/crm/v2/data/query）按 life_status=normal + k3_sync_fields_last_modify__c >= 1小时前 增量拉取客户，结合 Address/Contact 对象补全地址与联系人，写入 K/3 的 t_Item、t_Organization 表。
销售订单同步：/k3/sync-seorder 是核心，按 FBillNo + FHeadSelfS0170 来源标识判定新建/修改，调用 GetICMaxNum 存储过程获取 FInterID，通过 t_billcodeby 生成 XSDD15+yyyymmdd+流水号 形式的单据编号，写入 SEOrder 主表、明细表后执行 p_UpdateBillRelateData 重建关联。
辅助工具：地址智能解析（/util/parse-address-info）将「姓名+电话+省市区+详细地址」一锅端的混合文本拆分为结构化字段；客户档案修订接口（/account/update-account-number）支持必要时调整 K/3 客户编码。
3. 业务流程、功能路径描述
被动同步（客户）：纷享销客工作流回调 GET /fxapi/sync-accounts → 服务 60 秒后异步拉取最新客户 → 写入 K/3。主动同步（客户）：APScheduler 每小时执行 sync_accounts_from_fxiaoke_to_k3 → 调用本地 accounts_by_filters → 拉取增量客户 → 写入 K/3。
订单同步：纷享订单审批完成后回调 POST /k3/sync-seorder → 服务按
项目实现
1. 整体架构和设计思路，不同模块使用的技术栈
整体架构：采用「单体服务 + 多线程生产部署」的轻量架构，Flask 负责路由分发，Waitress 作为生产 WSGI 服务器（4 线程，监听 0.0.0.0:43686），APScheduler 以 BackgroundScheduler 形式同进程内托管后台任务；通过 Flask 的 g 对象 + teardown_appcontext 实现请求级 DB 连接隔离，避免全局连接在多线程下被并发踩踏。
技术栈：
Web：Python 3.11 + Flask 3.1.3 + Waitress 3.0.2
数据：pyodbc 5.3.0（直连 SQL Server 2008 R2）
集成：Requests 2.33.1（调 https://open.fxiaoke.com OpenAPI）
调度：APScheduler 3.11.2（Asia/Shanghai 时区）
日志：logging + TimedRotatingFileHandler（按天滚动、保留 30 天、all/info/error 三级目录）
2. “我” 的负责模块和结果（尽可能量化）
我独立完成整个服务的需求拆解、架构设计、编码与上线，核心成果如下：
25+ 个 REST API 路由，覆盖 K/3 六大业务实体的查询/同步。
完成 6 个客户自定义字段、17 个订单明细自定义字段的对接映射（含色号、工艺、幅宽、缸号、回扣单价/金额/回扣后金额等业务特有字段）。
纷享 Token 二级缓存机制（corpAccessToken 缓存 2h、openUserId 缓存 1h，提前 5 分钟失效），将高频接口的鉴权请求降低 99%。
订单号生成器（XSDD15+yyyymmdd+N 位流水），通过 UPDLOCK, HOLDLOCK 行锁解决高并发下 t_billcodeby 唯一性冲突。
订单同步链路：单条订单从「接收→生成 FInterID→写主表→删后插明细→跑关联存储过程」平均耗时 < 300ms。
三级日志目录（all/info/error）按天滚动 30 天，定位故障链路缩短到分钟级。
3. “我” 遇到的难点、坑，和解决方案
K/3 SQL Server 2008 R2 多部分名称无法绑定（错误 4104）：JOIN 多表查询自定义字段（如 SaleOrder.FHeadSelfS0169）时报错。解决：调整查询策略，必要时拆为单表查询 + 程序内关联，避免多部分标识符。
K/3 中存在同 FBillNo 的手工订单，误更新会覆盖财务数据：直接按 FBillNo 更新存在数据安全风险。解决：在 UPDATE WHERE 中加 FHeadSelfS0170 != ''（纷享来源标识），仅更新由本服务写入的订单。
SEOrde
整体架构：采用「单体服务 + 多线程生产部署」的轻量架构，Flask 负责路由分发，Waitress 作为生产 WSGI 服务器（4 线程，监听 0.0.0.0:43686），APScheduler 以 BackgroundScheduler 形式同进程内托管后台任务；通过 Flask 的 g 对象 + teardown_appcontext 实现请求级 DB 连接隔离，避免全局连接在多线程下被并发踩踏。
技术栈：
Web：Python 3.11 + Flask 3.1.3 + Waitress 3.0.2
数据：pyodbc 5.3.0（直连 SQL Server 2008 R2）
集成：Requests 2.33.1（调 https://open.fxiaoke.com OpenAPI）
调度：APScheduler 3.11.2（Asia/Shanghai 时区）
日志：logging + TimedRotatingFileHandler（按天滚动、保留 30 天、all/info/error 三级目录）
2. “我” 的负责模块和结果（尽可能量化）
我独立完成整个服务的需求拆解、架构设计、编码与上线，核心成果如下：
25+ 个 REST API 路由，覆盖 K/3 六大业务实体的查询/同步。
完成 6 个客户自定义字段、17 个订单明细自定义字段的对接映射（含色号、工艺、幅宽、缸号、回扣单价/金额/回扣后金额等业务特有字段）。
纷享 Token 二级缓存机制（corpAccessToken 缓存 2h、openUserId 缓存 1h，提前 5 分钟失效），将高频接口的鉴权请求降低 99%。
订单号生成器（XSDD15+yyyymmdd+N 位流水），通过 UPDLOCK, HOLDLOCK 行锁解决高并发下 t_billcodeby 唯一性冲突。
订单同步链路：单条订单从「接收→生成 FInterID→写主表→删后插明细→跑关联存储过程」平均耗时 < 300ms。
三级日志目录（all/info/error）按天滚动 30 天，定位故障链路缩短到分钟级。
3. “我” 遇到的难点、坑，和解决方案
K/3 SQL Server 2008 R2 多部分名称无法绑定（错误 4104）：JOIN 多表查询自定义字段（如 SaleOrder.FHeadSelfS0169）时报错。解决：调整查询策略，必要时拆为单表查询 + 程序内关联，避免多部分标识符。
K/3 中存在同 FBillNo 的手工订单，误更新会覆盖财务数据：直接按 FBillNo 更新存在数据安全风险。解决：在 UPDATE WHERE 中加 FHeadSelfS0170 != ''（纷享来源标识），仅更新由本服务写入的订单。
SEOrde
示例图片视频
相似推荐
会员管理系统（微信小程序 + WEB 收银运营端 + Spring Boot 后端）-XX 会员中心
面向单品牌多门店实体经营场景的会员管理系统，一套后端同时支撑微信小程序端（会员自助）与 WEB 管理端（收银与运营）。
小程序端（14 个页面）：会员资产总览、60 秒动态刷新核销码、在线充值、钱包与余额流水、卡券包、消费账单、等级权益、门店导航、推荐有礼、生日礼、消息中心与绑定手机号。
WEB 管理端（22 个页面）：收银台（三区布局、Pad 适配、挂单/取单、现金/储值/组合支付与结算打印）、会员 360°、会员导入导出、对账中心、券模板与发券向导、等级规则可视化构造器、推荐有礼、生日礼、消息中心、门店与员工管理、业绩排行、经营看板（ECharts）、RBAC 权限与操作日志、支付单管理。
核心机制：会员资产按「本金 / 赠送 / 积分 / 成长值」四账分离——赠送不可退、消费优先扣赠送、赠送抵扣不计积分，从模型上堵住充值套现与刷等级；每笔资产变动写不可变流水（含变更前后快照），并配 T+1 自动对账校验余额恒等于流水合计。营销侧覆盖券模板、定向与条件批量发券、券锁定与并发安全核销、次卡售卡核销、推荐有礼、生日礼与消息中心。支付做成可插拔渠道（IPayChannel 抽象），当前 Mock 渠道已跑通全链路，微信支付 APIv3 骨架（请求签名 / 回调验签解密 / 平台证书自动下载 / 就绪自检）已就绪，补齐商户参数即可真实收款，业务代码与数据库零改动。
本项目为个人独立完成的练习作品，未曾商用，业务数据均为自检脚本生成的测试数据。
餐饮门店点单小程序
餐饮门店扫码点单小程序，前后端分离架构。前端采用微信原生小程序 JS/WXML/WXSS，后端 Python FastAPI+MySQL。实现桌码扫码点餐、菜品分类、规格选择、购物车、订单提交、状态查看；配套 Web 后台管理菜品、订单、营业统计，支持小票打印，减少人工接单压力。
基于Arduino Leonard开发板的第三方街机控制台
为下落式音乐游戏SDVX开发第三方控制器。基于Arduino Leonard开发板实现。实现按键、编码器旋钮输入采集、通过 USB 模拟游戏手柄，向PC运行的游戏程序传输操控信号。硬件采用压接端子接线，免去频繁焊接，方便后期设备维护，成品接入电脑可体验。
汽车维修保养
汽车行业维修保养全部流程;小程序定制开发，拥有数十名专业技术人员，提供产品设计、开发、测试、上线运维一站式数字化解决方案。为多行业客户定制开发应用系统，助力企业数字化型;实现了汽车行业从维修到保养的全部流程业务
私域商城分销体系+AI智能体搭建项目-玩趣优品商城
项目为新零售私域电商平台，搭建会员折扣与二级推广激励体系，完成分销佣金规则合规梳理。配套基于Coze扣子平台搭建AI智能体，用于客服接待、客户咨询、推广规则自动讲解。支持VIP会员充值、推广员资格管理、推广业绩数据统计，前端包含H5落地页、商城小程序页面，帮助商家实现客户裂变、私域用户维护。
帮助文档
Copyright @ 2021-2024 程聚宝 | 浙ICP备2021014372号
人工客服