零售系统选型需要把功能名称落实到具体业务。本文依据PEKON售前沟通中的真实问题，整理30个具体问题，按门店交易、库存运营、会员渠道和上线扩展整理，说明现有能力、项目定制及需要进一步确认的范围。

例如，同样是改价，需要分清最低折扣和授权层级；同样是库存管理，需要分别讨论商品转换、盘点和渠道分配。关于产品适配、系统替换与长期服务，可参阅品牌零售系统选型与换代专题。

门店交易与商品管理

零售系统需要记录商品、价格、促销与实际交易结果。PEKON将这些内容放入门店操作流程，使交易处理与后续查询能够对应。

不同门店能不能设置不同促销？

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

店员临时改价，能不能限制最低折扣？

可以配置最低折扣，并通过店长授权控制临时改价。店员改价时需要店长输入授权码；例如总部规定最低八折，即使店长授权，低于八折的价格也无法提交。

改价能不能按折扣力度设置多级审批？

目前改价控制只有店长授权这一级，不支持按折扣力度继续设置多级审批。若品牌希望实现店长、区域经理和总部逐级审批，需要另行评估，不能把店长授权理解为已具备多级审批。

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

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

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

正常退货怎样关联原销售单？

退货需要查找并关联原销售单发起。系统支持整单退货及部分商品退货；涉及赠品、折扣等组合优惠时，需要按原单和优惠分摊规则处理，并核对退回商品及对应金额。复杂促销订单应先确认适用的退货处理方式，不能仅按商品现价退款。

同店等价或高价换货怎么处理？

同店换货按商品价格差异处理：等价商品可以更换，换成价格更高的商品需要补差价。涉及向顾客退还差额的低价商品，不作为这里的换货流程，应按适用的退货流程另行处理。原交易、退回商品和换出商品应保持可查的对应关系。

实体套装和虚拟套装，库存有什么区别？

实体套装作为独立SKU发货、记录库存并销售；虚拟套装本身不单独持有库存，销售时扣减各组件SKU库存。品牌应根据商品实际包装、发货和销售方式确定采用哪种管理方式。

促销组合是否等于BOM库存管理？

不等于。促销规则也能形成组合销售效果，但其重点是优惠计算；BOM管理处理套装与组件的库存关系。选型时需要分别确认组合售价如何计算，以及交易后扣减哪个SKU的库存。

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

可以通过商品转换处理：按预设组成数量减少盒装库存、增加单片库存，之后销售单片时再扣减单片SKU库存。不能只把盒装售价除以片数，而不处理库存单位和商品对应关系。

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

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

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

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

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

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

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

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

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

不过，补录权限、允许补录的日期范围，以及历史补录对库存和财务日结产生的具体影响，还需要结合项目规则进一步确认。这些规则应在上线前确认，并在补录后核对对应业务记录。

库存与多门店运营

门店销售、调拨和盘点持续影响库存记录。PEKON围绕这些业务管理库存变化，并为总部和门店提供相应的数据与操作权限。

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

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

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

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

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

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

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

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

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

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

建议订货通常参考哪些业务数据？

现有项目通常结合近60天销量、门店现有库存、总仓库存、在途天数、未来促销活动、门店销售目标和装箱规则计算建议量。具体采用哪些因素、怎样计算，需要根据品牌的销售周期与补货规则确定。

建议订货的数据和单据怎样与ERP衔接？

总仓库存等供应链数据通常来自ERP，门店销量和促销数据来自零售系统。门店目标、在途信息和箱规的来源，需要按系统分工和接口方案确定。

完成定制后，门店新建订货单时可计算建议商品和数量；订货单按配置完成审核后推送ERP，由ERP生成发货单，再回传门店进行收货。数据准备、接口和审核规则需要一起确认。

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

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

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

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

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

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

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

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

分批盘点可与营业配合进行，但需要确认盘点期间销售等库存变化如何纳入核对，按项目规则安排盘点范围和时点。对于大型门店而言，选型时需要关注的不只是“有没有盘点”，而是系统能不能处理分批盘、差异复盘和营业过程中库存持续变化这些真实情况。

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

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

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

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

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

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

相关库存与门店能力可参阅PEKON智慧零售系统，具体流程与配置范围需结合品牌业务确认。

会员与渠道协同

会员身份、权益和交易记录需要在具体服务中衔接。相关建设应结合品牌已有会员和渠道系统说明，区分各系统的业务责任。

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

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

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

预订单怎样记录需求和锁定库存？

现有能力可以配置预订单是否锁定库存。有可用库存时，可按配置锁定相应数量；暂时无货时，先记录预订需求，到货后再按规则分配和锁定。库存报表分别体现总库存、锁定库存和可用库存。

VIP顾客能不能优先锁库存？

目前不支持按客户等级或订单优先级分配库存锁定顺序。支持预订单锁库存，并不等于支持VIP优先或高优先级订单抢占库存；这两项能力需要分开判断。

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

可以通过虚拟仓区分不同渠道的库存份额。虚拟仓是系统中的库存账户，不要求现实中存在独立物理仓库。例如10件商品可按业务安排分为淘宝闪购3件、美团2件、线下门店5件。

各渠道能否读取对应库存、订单如何下发以及售后如何回传，需要结合OMS或全渠道中台、平台接口与零售系统共同确定。库存份额调整也应明确规则和执行方，不能仅凭零售系统设置虚拟仓就认为所有渠道已经自动连接。

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

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

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

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

会员身份、等级、积分与权益管理可进一步参阅PEKON CRM会员中心。门店按品牌规则使用权益并保留交易记录，涉及渠道履约时还需与订单系统配合。

系统上线与后续扩展

PEKON将数据准备、培训和业务切换纳入实施安排，并围绕后续门店、渠道和组织变化规划扩展。零售系统选型中的功能确认，也应同时说明产品版本、接口与定制范围。

建议订货是所有客户共用的标准算法吗？

不是。本文所述建议订货属于按品牌需求定制的能力，不是所有客户共用同一套固定算法。通常需要先上线并积累门店数据，再结合品牌的库存策略、销售周期和补货规则进行定制。

零售系统选型时，应区分已经使用的标准功能、既有项目定制和本项目仍需评估的内容，同时确认数据准备、实施安排和后续维护范围。

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

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

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

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

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

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

涉及旧系统替换时，商品、库存、会员及未完成业务的迁移范围，需要与培训、门店切换及上线核对共同安排。实施过程可参阅零售系统更换与迁移的五步实践。

零售系统选型的关键，是把每项需求对应到可演示的流程、数据来源和实施范围。清楚说明标准功能、已有定制及待评估内容，才能让双方对上线后的使用方式形成一致预期。