业务和功能介绍
- 在不改变数据结构的前提下，完成“混合购物车 + 混合订单”新规则落地：
- 支持普通商品与福利商品在同一购物车中共存、一次勾选统一结算；
- 同一订单内按明细区分福利商品与普通商品，福利行禁优惠、仅换货，普通行沿用原优惠与售后规则；
- 自动下单仍仅针对“全福利单”，不受混合订单改造影响。
- 补齐福利模块在自动下单、售后、报表侧与 PRD 的差异，保证链路从“功能可用”走向“规则对齐、可审计”。
等等就不一一列出
- 支持普通商品与福利商品在同一购物车中共存、一次勾选统一结算；
- 同一订单内按明细区分福利商品与普通商品，福利行禁优惠、仅换货，普通行沿用原优惠与售后规则；
- 自动下单仍仅针对“全福利单”，不受混合订单改造影响。
- 补齐福利模块在自动下单、售后、报表侧与 PRD 的差异，保证链路从“功能可用”走向“规则对齐、可审计”。
等等就不一一列出
项目实现
- **M1-1 购物车层改造（cart 共存 + 价格计算）**
- 放开 `CartServiceImpl.calculatePrice` 中“福利购物车与普通购物车不可混用”的硬拦截，允许同一批次勾选普通+福利条目。
- 保持 `Cart.cartType`、`Cart.welfareActivityId` 与 `CartInfoResponse.cartType/welfareActivityId` 语义不变，前端通过响应区分展示普通/福利商品。
- 在价格计算时：
- 对福利条目：不参与优惠券/满减/积分/SVIP 折扣，只计算原价（+运费按后续策略处理）；
- 对普通条目：继续执行原来的优惠券/积分逻辑。
- 验收点：混合勾选场景可以正常返回价格明细；普通商品仍可使用优惠，福利商品部分金额不受优惠影响。
- **M1-2 预下单与福利金额校验（按“福利商品小计”）**
- 在构建 `PreOrderInfoVo` / 预下单快照时，为明细增加“是否福利商品”的标记（如在 VO 层增加 `welfareItem`，从购物车 `cartType` 推导）。
- 同步调整福利校验与自动兜底逻辑：包括 `validateWelfareScene`、`autoFillWelfareIfNecessary`、`resolveUserWelfareCard` 等方法，改为在混合购物车场景下仅对福利条目做活动与商品池校验，允许普通购物车条目共存。
- 将 PRD 中“手动单金额校验”落地为：
- 仅对“福利商品小计金额”与福利卡面额进行三档校验（=面额、>面额、<面额）；
- 不足时返回 `WELFARE_AMOUNT_NOT_ENOUGH`，文案为“福利商品金额未达到福利卡使用标准，请凑满 {diff} 元”；
- 自动下单仍保持原有“订单金额=面额”严格等额策略。
- 验收点：
- 纯福利单/混合单下，福利商品小计 < 面额时均被阻断；
- 纯普通单不触发福利校验。
- 【现状备注】当前 `PreOrderInfoVo` 已包含订单级 `welfareType/welfareCardId`，预下单和创建订单阶段已实现福利订单金额校验与 `WELFARE_AMOUNT_NOT_ENOUGH` 错误码，但校验口径基于“整单金额”且 `validateWelfareScene` 要求全部购物车条目为福利车，后续需按本计划改造为“明细级福利标记 + 福利小计金额校验”。
- **M1-3 优惠券与积分仅作用于普通明细**
- 在预下单、价格计算与创建订单阶段（`FrontOrderServiceImpl` 中涉及优惠/积分的逻辑）统一调整：
- 放开 `CartServiceImpl.calculatePrice` 中“福利购物车与普通购物车不可混用”的硬拦截，允许同一批次勾选普通+福利条目。
- 保持 `Cart.cartType`、`Cart.welfareActivityId` 与 `CartInfoResponse.cartType/welfareActivityId` 语义不变，前端通过响应区分展示普通/福利商品。
- 在价格计算时：
- 对福利条目：不参与优惠券/满减/积分/SVIP 折扣，只计算原价（+运费按后续策略处理）；
- 对普通条目：继续执行原来的优惠券/积分逻辑。
- 验收点：混合勾选场景可以正常返回价格明细；普通商品仍可使用优惠，福利商品部分金额不受优惠影响。
- **M1-2 预下单与福利金额校验（按“福利商品小计”）**
- 在构建 `PreOrderInfoVo` / 预下单快照时，为明细增加“是否福利商品”的标记（如在 VO 层增加 `welfareItem`，从购物车 `cartType` 推导）。
- 同步调整福利校验与自动兜底逻辑：包括 `validateWelfareScene`、`autoFillWelfareIfNecessary`、`resolveUserWelfareCard` 等方法，改为在混合购物车场景下仅对福利条目做活动与商品池校验，允许普通购物车条目共存。
- 将 PRD 中“手动单金额校验”落地为：
- 仅对“福利商品小计金额”与福利卡面额进行三档校验（=面额、>面额、<面额）；
- 不足时返回 `WELFARE_AMOUNT_NOT_ENOUGH`，文案为“福利商品金额未达到福利卡使用标准，请凑满 {diff} 元”；
- 自动下单仍保持原有“订单金额=面额”严格等额策略。
- 验收点：
- 纯福利单/混合单下，福利商品小计 < 面额时均被阻断；
- 纯普通单不触发福利校验。
- 【现状备注】当前 `PreOrderInfoVo` 已包含订单级 `welfareType/welfareCardId`，预下单和创建订单阶段已实现福利订单金额校验与 `WELFARE_AMOUNT_NOT_ENOUGH` 错误码，但校验口径基于“整单金额”且 `validateWelfareScene` 要求全部购物车条目为福利车，后续需按本计划改造为“明细级福利标记 + 福利小计金额校验”。
- **M1-3 优惠券与积分仅作用于普通明细**
- 在预下单、价格计算与创建订单阶段（`FrontOrderServiceImpl` 中涉及优惠/积分的逻辑）统一调整：
示例图片视频
相似推荐
外卖点餐项目
（一）管理端：商户运营的 “智能中枢”
面向餐饮企业内部员工，提供全流程运营管理工具，核心功能涵盖六大模块：
组织与权限管理
支持员工账号的创建、编辑与禁用，基于角色的权限分配机制确保操作安全，例如管理员可配置后厨员工仅查看订单权限，财务人员专属数据统计权限。
商品全生命周期管理
分类管理：维护菜品与套餐分类，支持新增、删除及状态切换，适配餐厅菜单迭代需求；
菜品 / 套餐管理：实现信息录入、图片上传、价格调整、启售停售控制，还支持菜品口味细分配置。
订单高效履约系统
实时接收用户订单，通过 WebSocket 实现新订单语音播报，支持订单查询、取消、派送、完成全状态处理，还可导出订单报表用于财务核对。
数据驱动决策中心
生成营业额、用户增长、订单趋势等多维度报表，按日 / 周 / 月统计销售数据与订单量，辅助商家优化菜品结构与促销策略。
堂食场景适配
支持商家配置堂食订单流程，用户下单后生成取餐码，后厨接单后同步通知前厅备餐，实现堂食与外卖订单分流管理。。
（二）用户端：便捷点餐的 “移动入口”
基于微信小程序搭建，聚焦消费者点餐全流程体验，核心功能包括：
轻量化登录与首页体验
支持微信授权一键登录，首页展示分类导航、热门菜品推荐及店铺活动，通过搜索栏可快速定位目标菜品。
精细化购物车操作
支持添加菜品、调整数量、删除商品，适配多规格菜品（如微辣 / 中辣、小份 / 大份）选择，提供一键清空与结算功能。
全流程订单服务
下单环节：可选择外卖配送（管理收货地址）或堂食取餐，支持备注特殊需求；
支付与售后：集成微信支付，实时显示支付状态，支持订单催单、退款申请及历史订单查询。
智能化服务升级
个人中心管理
可维护多个收货地址，查看订单详情与物流状态，修改个人信息及账号安全设置。
智能对话机器人
从无到有搭建的一个以金融为中心的机器人，主要里面涉及三个模块NLU和NLG，
以及最后一个对话管理DM模块组成，以机器代替人工，24小时随时接待，让客户随时享
受服务，体验机器带来的方便，解决了一些用户常问的问题。里面主要包括功能有：基金
的查询、保险的查询、以及推荐保险，天气查询等功能。通过用户的查询迅速以语音的方
式返回给用户想要了解的问题的答案，实现快速问答。
商业球房管理系统-客稻云
1. 立项背景与目标
针对传统大中型台球俱乐部普遍依赖手工记录台费、财务对账繁琐、多门店管理混乱、会员营销手段单一等核心运营痛点，我独立全栈设计并开发了这套商业球房管理系统。项目核心目标是构建一个一体化、数字化、智能化的运营平台，通过技术手段实现从顾客入场到离店结算的全流程自动化管理，并打通多门店数据，为经营者提供实时决策支持，最终达到降本增效、提升营收与客户体验的商业目的。系统上线后已稳定运营两年，验证了其可靠性与实用性。
2. 软件功能与核心模块介绍
系统采用模块化设计，核心功能模块围绕“人、货、场”的精细化运营展开：
（1）核心运营模块：包括台桌管理（支持大型球房分区、排班与状态实时监控）、助教管理（排班、绩效与订单绑定）、消费流程核心（上桌开单、智能计费、多种方式结算）以及店内外卖系统，覆盖线下服务全场景。
（2）管理与决策模块：包含多门店管理（总部统一管控各分店资源、价格与会员体系）、客户关系与营销管理（会员等级、积分、储值、优惠券与营销活动）、以及报表与财务中心（自动生成每日营业报表、门店财报、助教提成、商品销售分析等），实现数据驱动的经营决策。
（3）基础支持模块：涉及角色权限管理、系统操作日志、硬件（扫码枪、打印机）对接等，保障系统稳定与安全。
3. 业务流程与功能路径描述
系统的核心业务流程遵循顾客消费动线，形成管理闭环：
（1）入场与开台：顾客到店（或通过预约），前台在系统“台桌视图”中选择空闲台桌开单，可关联指定助教，系统自动开始计时计费。
（2）消费中服务：过程中，顾客可通过扫描台卡二维码在手机端点购外卖（饮品、小吃），订单实时推送至后厨与前台。所有消费项目实时挂单至该台桌账单。
（3）结算与离店：顾客结账时，前台进入结算界面，系统自动汇总台费、商品费等，支持会员卡、积分、现金、移动支付等多种方式混合结算。支付成功后，系统自动释放台桌、更新库存，并生成账单。
（4）运营与复盘：每日营业结束后，店长通过“报表中心”一键生成当日门店财报，清晰展示营收、商品成本、助教绩效等核心数据。总部管理者可通过“多门店管理”后台，横向对比各店经营健康度，并基于“客户管理”模块数据分析，在“营销管理”中策划定向优惠活动，提升复购率。
房态管理系统APP-宿眸AI
1. 立项背景与目标
在民宿行业数字化升级的背景下，针对单体民宿或小型连锁品牌普遍存在的房态管理混乱、各渠道订单不同步、财务统计繁琐等痛点，我独立立项并全栈开发了此套民宿房态管理系统。项目核心目标是参考行业领先的“订单来了”产品逻辑，打造一个轻量、高效、低成本的一体化解决方案，帮助业主实现房源、订单、客户与财务的集中化、自动化管理，提升运营效率与客户体验。
2. 软件功能与核心模块
系统采用前后端分离架构，主要包含以下核心功能模块：
（1）房态与房源管理：可视化日历房态总览，支持批量调价、设置连住优惠、关房，并统一管理房源图片、设施等信息，一键同步至多个渠道。
（2）多渠道订单聚合：通过API接口自动同步来自美团、途家、微信小程序等渠道的订单，实现单一后台处理所有预订，彻底杜绝超卖。
（3）客户与财务管理：建立客户档案库，记录偏好与消费历史。集成财务看板，自动生成每日营收、渠道佣金、未来流水等报表，简化对账流程。
（4）智慧运营工具：包含智能房价策略建议、清洁任务自动派单、入住指引自动发送等提升效率的辅助功能。
3. 业务流程与功能路径
系统的核心业务流程围绕 “一个订单”的生命周期展开：
（1）房源上架与定价：业主在“房源管理”模块完善信息并设置基础价格后，可在“房态日历”上针对特定日期进行个性化定价或优惠设置。
（2）订单汇聚与处理：新订单无论来自哪个渠道，均实时汇聚至“订单中心”。系统会触发自动确认短信，并在日历上自动锁定对应房态。
（3）入住前服务：订单入住前夜，系统自动向客户发送含地址与密码的入住指引。同时，在“任务中心”生成一条清洁工单，通知保洁人员。
（4）结算与复盘：订单完成后，自动进入“财务管理”模块。所有收入、支出数据被结构化记录，业主可一键查看周期内的经营报表，为后续定价和营销提供数据决策。
4. 技术实现与成果
（1）技术栈：后端采用 PHP (thinkphp框架) 构建RESTful API，负责核心业务逻辑与渠道API对接；前端使用uniapp开发单页面应用，实现交互流畅的管理后台；数据库使用 MySQL，并利用 Redis 缓存高频访问的房态数据。
（2）项目成果：该系统成功帮助3家试点民宿实现了房态准确率与订单处理效率提升约70%，财务对账时间从平均半天缩短至1小时内，验证了产品设计的有效性，并积累了宝贵的全栈产品从0到1的研发与迭代经验。
县域文旅数字化管理平台-县域文旅小程序“嗨龙里”
“嗨龙哩”县域文旅小程序业务与功能介绍
一、项目背景与目标
实现龙里县县域旅游资源分散、信息不畅的痛点，本项目旨在打造一个集信息聚合、文化体验与便民服务于一体的数字化平台，以提升游客体验、传播地方文化并助力本地经济发展。
二、软件功能与核心模块
1、智能导览：提供景点百科、个性化路线规划与AR实景导航。
2、特色发现：整合本地美食地图、特产电商与活动日历预约。
3、互动社区：支持打卡分享、积分任务，形成旅行足迹与互动社区。
4、实用工具：集成交通查询、紧急联系及方言趣味翻译等便民功能。
三、业务流程与功能路径
1、游客核心路径：打开小程序→获取推荐路线→使用导览与导航→打卡消费与分享→积分兑换。
2、商户管理路径：在线入驻→上架商品/服务→参与营销活动。
3、管理后台：用于文旅部门统一更新内容、发布活动与管理数据。
帮助文档
Copyright @ 2021-2024 程聚宝 | 浙ICP备2021014372号
人工客服