在零售系统选型过程中，客户真正关心的问题，往往比一张标准功能清单具体得多。

本文选取 PEKON 售前顾问与客户在实际选型沟通中的真实问答，并在不改变原有业务场景和产品边界的基础上进行整理。这些问题来自客户对门店管理、库存、履约、促销及系统集成等具体场景的追问，也更接近企业进入方案沟通和 Demo 阶段后真正需要验证的内容。

促销能不能按门店设置？店员临时改价，总部能不能管住最低折扣？收货少了两件，是直接改实收数量，还是另外走差异流程？一万件库存能不能不关店盘完？线上订单来了，应该先从后仓拿货，还是直接动前场库存？

真正进入零售系统选型和 Demo 阶段后，问题往往会从“有没有 POS、库存、促销、会员”迅速变成这些具体场景。同样叫“支持促销”，背后可能是总部统一配置，也可能还涉及门店权限、店长授权和折扣下限；同样叫“支持补货”，有的只是手工订货，有的可以计算建议量，但算法又可能需要根据品牌规则单独定制。

因此，看一套零售系统是否适合自己的业务，不能只核对功能清单，还要继续问清三个问题：总部能管到什么程度？库存和履约流程能做到多细？系统明确不做什么？下面从这些真实选型问答出发，拆开看不同能力背后的实际业务边界。

一、总部管得住门店吗：权限、收货、员工操作与售后

连锁零售系统首先面对的是“统一”和“灵活”之间的平衡。总部希望促销、折扣、库存和业务流程可控，门店又必须处理破损、退换货、临时改价等现场情况。所以选型时，真正需要确认的并不只是“有没有权限管理”，而是：什么事情门店可以自己做，做到什么程度需要授权，发生过什么事情总部以后还能不能查清。

1. 不同门店能不能设置不同促销？改价权限能管到多细？

可以针对不同门店配置不同的促销活动。促销规则由后台统一配置，再由门店前端执行，因此总部可以决定哪些门店参加哪些活动。

如果涉及临时改价，目前采用的是店长授权方式。店员执行改价时，需要店长输入授权码，同时后台还可以配置最低折扣。例如，总部规定最低只能打八折，那么即使店长授权，低于八折的价格也无法提交。

这里需要特别注意一个边界：目前改价控制只有店长授权这一级，并不支持根据促销力度继续设置多级审批。也就是说，如果企业希望实现“九折店长审批、八折区域经理审批、七折总部审批”这样的逐级授权，需要另外评估。

2. 门店改过什么价格，总部以后能不能查？

可以。系统会保留改价流水和相关操作记录，用于后续查询、追溯和审计。

因此，选型时除了确认“能不能控制改价”，还应该同时确认异常发生以后能不能还原是谁、在什么时候、对什么业务进行了什么操作。权限解决的是事前控制，日志解决的是事后追溯，两者缺一不可。

3. 收货时发现破损或少货，能不能直接按实收数量处理？

技术上可以实现，但目前这类流程属于项目定制能力，并不是统一的标准流程。已有项目中，门店可以录入实际收到的数量，系统核对发货数量与实收数量后，自动生成差异退库单，并推送到 ERP。

不过，多数客户实际仍然更倾向于采用“两步处理”：先正常确认收货，再通过独立的差异流程记录照片、原因和审核信息。原因很现实，同样是“发了 10 件、门店收到 9 件”，背后可能分别意味着供应方少发、运输途中破损，或者门店收货后发生损坏。如果系统只把库存数量从 10 改成 9，库存数字虽然对上了，责任过程却没有留下来。

因此，这类场景选型时不能只问一句“能不能改实收数量”，还要进一步确认：差异原因怎么记录、责任怎么区分、证据在哪里留、是否需要审核。

4. 拍照考勤能不能完全防止代打卡？

不能完全杜绝，只能降低风险。目前系统要求员工现场拍照，不允许直接从手机相册上传已有图片，因此可以避免员工直接使用旧照片打卡。但如果是他人在现场代为拍照，单纯依靠拍照机制仍然无法完全排除。

目前系统也没有强制集成 WiFi 绑定或电子围栏定位。所以，如果企业把“严格防代打卡”作为重要管理目标，仅依靠现有拍照考勤并不足够。这也是系统选型时一个很典型的问题：一项功能存在，并不代表它可以解决这个业务问题的所有风险。

5. 能不能统计每个员工一天到底干了什么？

目前没有独立的员工个人活动报表或人效统计报表，但系统后台会记录完整操作日志，包括员工登录时间、操作时间、操作内容、业务对象以及修改记录。例如，可以追溯某个账号在几点几分操作了哪个商品或库位，以及数量从多少修改成多少。

这些数据已经能够用于审计和问题排查。但如果企业希望进一步回答“某员工一天处理了多少任务”“不同员工的人效差异是多少”之类的问题，还需要在这些底层操作数据之上继续构建报表和指标体系。因此，“有操作日志”和“有人效分析”是两种不同能力，选型时不应混为一谈。

6. 正常退货怎么处理？换货是不是另一套流程？

正常退货需要关联原销售单，通过查找原单发起。系统支持整单退货，也支持部分商品退货。如果原订单中存在赠品或者折扣，则按照原销售单以及优惠分摊后的金额进行处理。

换货则根据商品价格差异处理。等价商品可以直接更换；如果换成价格更高的商品，需要补差价；如果换成价格更低的商品，需要向顾客退还差额时，则单独办理退货。

对于零售企业来说，这类能力真正需要确认的是：退换货是否仍然围绕原交易闭环，而不是脱离原单重新制造一笔无法追溯的业务。

二、货为什么总对不上：补货、BOM、盘点与全渠道库存

库存通常是零售系统 Demo 中最容易被一句“支持库存管理”带过的模块，但不同品牌真正遇到的问题完全不同。有的门店 SKU 多、库存大，最关心不停业盘点；有的品牌整箱订货，算法算出 10 件，但仓库只能发 24 件一箱；还有的同时做门店、即时零售和线上平台，需要决定同一批库存到底给谁卖。

因此，库存能力需要沿着订多少、怎么变、怎么盘、怎么分几条流程分别判断。

7. 建议订货到底是怎么算出来的？

不同品牌的计算逻辑会不同。现有项目中，建议订货通常会综合参考七类因素：近 60 天销量、门店现有库存、总仓库存、在途天数、未来促销活动、门店销售目标以及装箱规则。系统会综合销售需求、当前可用库存以及补货约束，计算建议订货数量。

其中的数据也并不全部来自同一系统。例如，总仓库存等供应链数据通常来自 ERP；门店销量和促销活动等数据来自零售系统。至于门店目标、在途信息、箱规等数据具体由哪套系统提供，则需要根据双方的系统分工和接口方案确定。

这里还有一个很重要的选型边界：建议订货目前属于按品牌需求定制的功能，并不是所有客户共用同一套固定算法。不同品牌的销售周期、库存策略和补货逻辑都可能不同，通常需要系统上线并积累一段时间的门店数据之后，再结合真实业务规则进行定制。

定制完成后，门店新建订货单时，系统可以自动计算本次建议订哪些商品、每件订多少，而不需要导购逐个添加商品。订货单本身还可以配置审核流程，完成审核后再推送 ERP，由 ERP 生成发货单并回传门店进行收货。

8. 系统建议订 10 个，但导购觉得应该订 15 个，怎么办？

建议量可以允许调整，但总部可以限制调整范围。例如，系统建议订货 10 个，总部配置允许上浮 20%，那么门店最多可以把数量调整到 12 个，超过允许范围后就不能直接提交。

至于特殊情况下是否允许门店另外创建手工订货单，以及手工单是否需要继续审批，需要根据具体项目规则确定。这类设计的核心，是在算法建议和门店经验之间留出空间，同时又避免建议订货最后变成完全由门店自由填写。

9. 系统算出要订 10 个，但仓库一箱只能发 24 个怎么办？

补货算法计算出的“业务需求量”，不一定就是最终订单数量。系统可以先计算需求，再根据品牌预先配置的装箱规则进行取整。

例如某商品一箱 24 个，而这次只计算出需要补 10 个，可以根据规则决定本次暂时不订，留待下一周期合并；如果计算结果已经接近一整箱，也可以根据规则向上取整到 24 个。所以，评价一个补货算法不能只看“预测得准不准”，还要看它有没有把实际供应链约束纳入最终下单逻辑。

10. 一盒面膜拆成一片一片卖，库存怎么扣？

这个场景涉及 BOM 与商品转换。正向 BOM 严格来说主要有两种库存处理方式：第一种是实体套装，套装本身作为独立 SKU 发货、记录库存并完成销售；第二种是虚拟套装，套装本身不单独持有库存，销售套装时，系统直接扣减其中各组件 SKU 的库存。

此外，通过促销规则也可以做出类似“组合销售”的效果，但需要区分：促销组合属于促销规则，并不等于 BOM 库存管理。

反向 BOM 则适用于大包装拆成小包装或单件销售。例如库存原本按照“一盒面膜”管理，但门店需要按“片”销售，就可以先通过商品转换减少盒装库存，再按照预设组成数量增加单片库存。之后销售单片面膜时，再扣减单片 SKU 的库存。

11. 门店临时拼了一个小礼包，需要先去 ERP 建商品吗？

可以直接在 POS 端创建临时组合商品，并按照礼包内原有组件扣减库存。交易完成后，可以将组件销售数据和结算数据回传 ERP。

至于这个“临时组合商品”本身是否也需要同步到 ERP，则不能一概而论，需要根据双方的商品主数据管理方式和接口方案确定。这个场景体现了一个常见的系统分工问题：前端为了快速完成销售可以有一定灵活性，但谁负责维护正式商品主数据，仍然必须提前定义清楚。

12. 一万件货，能不能不关店完成盘点？

可以。针对 SKU 数量和库存量较大的门店，后台可以下达盘点指令并生成盘点任务。门店按照商品品类分批进行盘点，完成一个品类之后可以先提交。没有盘差，或者盘差在允许范围以内的 SKU，可以结束本轮盘点；差异较大的 SKU 再进行复盘。

因此，门店不需要为了完成整店盘点而暂停营业，正常销售仍然可以继续进行。对于大型门店而言，选型时需要关注的不只是“有没有盘点”，而是系统能不能处理分批盘、差异复盘和营业过程中库存持续变化这些真实情况。

13. 四五个人同时盘一家店，结果怎么汇总？

系统支持多人协作盘点。可以按照门店区域或任务范围进行分工，每个人使用 PDA 完成各自的盘点任务。完成后，各个任务的结果会汇总到同一张盘点主单，再统一核对差异并进行复盘。

如果出现重复扫描或者不同任务范围重叠，具体应该如何处理，则需要结合实际盘点规则进一步确认。如果商品本身采用唯一码管理，例如二维码或者 RFID，也可以配合具备红外扫码或 RFID 识别能力的盘点设备，提高批量识别效率。

14. 线上订单来了，先从后仓拣，还是先拿前场货架上的商品？

系统可以配置“后仓库存优先、前场库存补充”的库存分配规则。订单进入之后，系统先判断后仓是否存在可用库存，库存不足时，再使用前场库存。

但这里需要特别区分两个概念：库存分配优先级，不等于员工实际拣货路径规划。现有能力可以决定系统先使用哪一部分库存，但 PDA 根据门店库位自动规划员工行走路线，目前还不是标准功能。在 Demo 中，这两个问题如果只问成一句“支不支持后仓优先拣货”，很容易产生理解偏差。

15. 门店只有 10 件货，怎么分别留给淘宝、美团和到店顾客？

可以通过虚拟仓区分不同渠道库存。虚拟仓本质上是系统里的渠道库存账户，并不要求现实中一定存在独立的物理仓库。

例如门店实际有 10 件商品，可以给淘宝闪购分配 3 件、美团分配 2 件、门店线下零售分配 5 件。淘宝订单只读取淘宝闪购虚拟仓，美团订单只读取美团虚拟仓，门店 POS 则读取门店零售仓。这样，不同渠道看到的并不是完全相同的一份“门店总库存”，可以降低多个渠道同时售卖导致的超卖风险。系统还可以根据各渠道的销售情况动态调整库存分配比例。

三、系统边界在哪：促销、预订、履约与 ERP 到底谁负责什么

成熟零售品牌很少只运行一套系统。POS、ERP、会员、小程序、第三方平台以及各种履约工具往往长期共存。因此，系统能力越多，并不意味着所有流程都应该放进同一个系统。

选型时更重要的是提前确认：促销由谁计算？ERP 管到哪里？库存什么时候锁？线上订单怎么下发？哪些需求属于现有标准能力，哪些需要继续评估？

16. 促销规则一定要从 ERP 下发吗？

通常不需要。促销活动一般直接在零售系统后台进行配置，并由前端执行，目前也通常不会去对接 ERP 内部的促销规则。

原因在于，零售促销本身可能包含打折、满减、套装以及多种复杂优惠算法，如果两套系统同时维护促销规则，对接复杂度会明显增加。现有系统已经具备独立的促销引擎，因此可以由零售系统统一配置，再由 POS、小程序等前端调用。

目前支持的促销形式包括满赠、满减、加价购、买一赠一、第二件半价、买 A 送 B，以及多件商品按照规则减免一件等。具体活动门槛、适用商品、赠品范围和优惠计算方式，都可以在后台进行配置，POS 与小程序可以调用同一套促销规则执行。

17. 已经有 POS，不想整体更换，能不能只用促销引擎？

存在这种使用方式。已有少量客户保留原有 POS 或小程序前端，只使用现有促销后台配置活动。结算时，客户原有前端通过接口调用促销引擎，获取促销计算结果，再由原有前端继续完成销售和结算。

这种方式更适合原有前端仍然能够继续使用，但促销能力不足，同时整体更换前端成本较高的场景。需要说明的是，目前这种模式确实存在，但客户数量相对较少。

18. 顾客退货不想退现金，能不能退到会员账户？

可以退到会员储值账户，顾客后续消费时可以使用储值余额支付，也可以通过发放电子优惠券，在下一次交易中进行核销。但目前不支持把退款金额直接转成会员积分。

因此，“退到账户”还需要继续问清楚，究竟指储值、优惠券还是积分，不同账户在系统中属于不同业务对象。

19. VIP 顾客能不能比普通顾客优先锁库存？

目前不支持按照客户等级或者订单优先级，对库存锁定顺序进行分配。现有能力是配置预订单是否锁定库存，但还没有进一步扩展到“VIP 优先”“高优先级订单优先”这样的分配逻辑。

如果商品当前已经存在可用库存，预订单可以根据配置直接锁定相应库存；如果暂时没有货，则先记录预订需求，待商品到货后再按照规则分配和锁定。库存报表中会分别体现总库存、锁定库存和可用库存。

所以，“支持预订单锁库存”和“支持根据客户优先级抢占库存”是两个不同问题。

20. 线上订单能不能自动形成波次，再推送到 PDA 拣货？

目前标准功能还不支持。现有流程仍然是线上订单到店后，由 POS 按订单打印小票，门店员工根据小票完成备货、拣货和打包，然后在系统中确认“备货完成”。之后根据订单履约方式，通知顾客到店自提、交给骑手，或者通过已经对接的快递服务完成发货。

至于波次汇总、PDA 任务推送以及按照库位进行拣货引导，目前属于待评估的定制需求。是否能够实现以及如何实现，需要结合实际订单来源、任务分配方式和设备接口继续评估。

这类问题在系统选型中尤其值得确认，因为“支持线上订单履约”并不自动等于“已经具备仓库级波次拣选能力”。

21. 海外业务一套系统能不能同时收美元和澳元？

币种可以按照不同运营体系进行配置。例如，澳大利亚运营体系可以配置澳元作为主币种。但在同一个运营体系内，目前只能使用一种主币种，不支持美元、澳元等多种币种同时混合结算。

因此，对于跨国家、跨地区经营的品牌，需要进一步确认自己的组织和运营体系如何划分，而不能只问系统“支不支持多币种”。

22. 百货代收款场景，大促当天来不及录单怎么办？

系统支持历史交易补录，可以选择实际交易日期进行补录。这项能力适用于百货代收款等交易已经实际发生、但门店当天无法及时在系统完成录入的场景。

不过，补录权限、允许补录的日期范围，以及历史补录对库存和财务日结产生的具体影响，还需要结合项目规则进一步确认。原始材料对这一部分没有给出完整结论，因此这里不继续补写。

四、为什么这些问题比一张功能清单更适合拿来选系统

把上面的真实问答放在一起看，会发现零售系统选型真正容易产生误判的地方，通常并不是系统完全“没有功能”，而是对同一句“支持”的理解不同。

“支持改价”，还要问有没有最低折扣、谁能授权、是否多级审批；“支持订货”，还要问有没有建议量、算法参考什么数据、是不是标准功能、门店能改多少；“支持盘点”，还要问能不能营业中盘、多人怎么协作、盘差怎么复盘；“支持线上订单”，还要区分库存分配、门店备货和仓储级波次拣货；“支持预订”，还要继续问是简单记录需求，还是锁库存，能不能再按客户级别分配；“支持多币种”，也要区分多个运营体系分别使用不同币种，和同一体系同时混合结算。

这些差异往往不会完整出现在一张标准功能表里，却会直接影响系统上线后的使用方式。

选型维度 Demo 时应该继续追问什么
权限与管控 谁可以操作？能做到几级授权？有没有金额、折扣或范围限制？
流程与异常 正常流程怎么走？发生差异、破损、缺货、退货时怎么处理？
数据与审计 操作有没有记录？以后能否追溯到人、时间和具体修改内容？
标准与定制 是现有标准功能、已有项目定制，还是仍需评估？
系统分工 POS、零售系统和 ERP 分别负责什么？哪些数据需要接口？
能力边界 系统明确不支持什么？一个相似功能是否容易被误解成另一种能力？

一套系统是否适合企业，并不取决于它能否给所有问题回答“可以”。很多时候，更有价值的答案恰恰是明确说明：这里目前只有店长一级授权；这里属于项目定制；这里可以做库存优先级，但不等于自动规划拣货路线；这里能锁库存，但不能按照 VIP 等级分配。

这些边界越早问清楚，企业越容易判断系统能力与自身业务之间到底有多大距离，也越容易把 Demo 从“看功能”变成真正的选型验证。