仙津 SRM 报价答疑
逐条回应 20 项会审意见

「询比价这一块是有招标的，你这里没有写……上次演示的时候就有开标招标」「保证金和中标通知书，应该放在询比价跟招标一起」

标准产品已含完整招标链：招标／邀请公告（含资质要求、报名与报价两个截止时间）→ 供应商报名与资格受理 → 投标保证金登记（未缴保证金即无效标的闸门）→ 未到截止不可开标 → 可配置评分项与否决阈值的评标 → 废标／流标／招标终止 → 中标通知书。

报价页把这一整条压缩成了「寻源管理」一行——呈现问题在我们，会后功能清单会把招标逐项展开列明。「保证金与中标通知书」与招标是同一条链，将合并呈现。

补充：贵司过去按份收取标书费（200 元／份）的做法，可在保证金同一收退链路上配置在线收取，属小增强，随范围一起确认即可。

「供应商要在门户网站上面做送货单打印……仓库应该知道我今天要收什么东西、要到多少」

标准已含。供应商在门户创建送货单（ASN）→ 打印带单头二维码的送货单与箱标 → 仓库 PDA 扫码收货、箱级防重复扫。送货单上还带车牌／司机／联系方式／车次与计划到货日期、到货时段（上午／下午／精确时刻）——仓库提前可见今日应到什么货、来多少。

「请款对账就是供应商这边发起，应该是标准功能，为什么它这里属于我新增的呢？」

对账协同本身是标准的：按周期生成对账单 → 供应商门户在线确认／异议／开票 → 盖章件回传与审核。

场景 5 收费的不是对账，而是三件增强：① ERP 侧对账数据对齐（对账单导入／接口同步，两套账对得上）② AI 发票与账单差异比对 ③ 请款包推送汇联易与财务集中审。会后清单会把「标准部分／定制部分」分列，一眼可分。

「三单匹配本身就是标准的，哪个财务收账都要有这些单」

对。基础三单匹配（订单-收货-发票）标准已含。场景 5 里计费的是贵司特有的「按采购类型分叉」：生产物料四单、辅料三单、服务两单、项目三单（合同＋PO＋里程碑验收单）——这套分叉规则目前靠财务人工判断，标准产品没有，需按贵司口径开发。

「合格与不合格应该是标准功能，异常上报你也收费？我这里有异常扣款、有 8D 啊」

对，这些都是标准：现场异常上报（拍照上传）、8D、SCAR 整改、索赔扣款。

场景 7 计费的是与 ERP 的打通：不合格品隔离任务触发 ERP 移仓、按异常类型走不同处置分支、让步接收会签、复检流程——「隔离-移仓-处置」的 ERP 联动是标准品没有的部分。

「这里不是有发票查重验证吗？那还去汇联易干嘛？」「建议能用汇联易已购的次数，不要再掏钱了」

查重（同一供应商同票号拦截）与「未验真不付款」闸门是标准已含。验真的查验通道本身需要外部服务——我们完全同意贵司的建议：对接汇联易已购的查验服务，发票传过去、验真结果回写 SRM，不重复采购查验次数。

需贵司与汇联易确认接口开放方式与是否额外收费；SRM 侧对接工作量小（见 C3）。

「只填结论，不填那些，这个明确说了……这不用做」

按会上结论调整范围：取消平板逐项录入检验原始数据的开发。保留链路为——仓库收货后自动推送检验任务 → 品控在平板只填结论（合格／不合格／让步）→ 结论推送 ERP；异常时携图片推送采购、供应商、仓管员。

「费用类和固定资产类的折旧均摊应该是 ERP 直接做，把那人天给他砍掉」

同意。均摊规则与执行留在 ERP；SRM 只做一件事——按费用类型把数据推送给 ERP，由 ERP 按财务口径处理。

「固定资产转固不是在 ERP 里面做吗？这个不用做了」

同意。转固在 ERP 做。SRM 保留两样：① 签收单二维码 ＋ 飞书扫码确认验收（不用再签字）② 验收结果接口推送 ERP，触发 ERP 侧转固。

「有些供应商没有飞书……挂在广东仙津公众号下面，300 个供应商就有 300 个粉丝」

好主意，分两层：

• 飞书单点登录：内部员工的飞书免登是标准已含；供应商侧飞书 SSO 可做，随门户一起交付。
• 微信公众号授权登录为新增：门户 H5 挂贵司服务号，供应商关注后授权即登录——公司动态、获奖信息也能顺路触达供应商，正是贵司说的「300 个粉丝」。

前置条件在贵司：认证服务号 ＋ 开通网页授权权限。工作量不大，评估后单独报价。

「供应商送货时直接把车辆预约了……时段满了就不能排；仓储审批确认，驳回就改时间同步供应商；快递除外」

现状一半已有：送货单上已带车辆信息与到货时段（上午／下午／精确时刻），仓库可见今日应到。会上要的新增是三样：

1. 时段容量控制：每时段限 N 台车，约满自动往后排（贵司说的「像停车场满位提示」）；
2. 仓储确认／驳回改期回路：驳回后调整到货时间并自动同步供应商，快递车辆除外；
3. 与行政来访预约（登记到保安室）打通——这一样牵涉行政侧系统是否配合开发，建议贵司内部先定口径，我们出对接方案。

「应该是开发 API 接口直接去调汇联易的接口……把发票传过去，把结果返回给我们」

与 A6 呼应：SRM → 汇联易查验服务的接口对接——发票信息传过去、验真结果返回并回写发票状态，驱动「未验真不付款」闸门。替代自购验真服务，不重复花钱。

待汇联易确认接口开放方式与费用后另报；SRM 侧预计工作量小。

「跟京东确定可以做 API 的话，直接把接口对过来……我们现在是下两遍单」

SRM 已含协议目录直采与商城框架（标准模块「综采与商城」）。与京东或其他电商平台的 API 直连，在贵司与平台谈妥后按接口对接另报——届时在 SRM 下单直接推送平台，不再两边各下一遍。

提醒：京东侧可能按年采购额度设开发门槛，平台接口费（如电商管家每年数千元）由平台收取，不在我方报价内。

「贵州诚数没听过，可信度不知道高不高」「我合作才查，不可能 300 家天天刷」「你们爬数据 IP 会封——有 API 一定用 API」

1. 数据源可插拔，选型由贵司拍板：企查查、天眼查的官方 API 填入贵司凭据即可接入（爱企查暂无对企业开放的标准 API）；贵州诚数只是低成本候选，贵司不认可即不用。查询费按次据实结算（报价「不含」中已列明），不产生绑定。
2. 调用频率完全可配：默认「纳入合作前按次查」；批量排查支持按周／按月定时，且带总次数上限闸门——预算包用尽自动停。不存在「300 家供应商每天全量刷」。
3. 合规原则与贵司完全一致：有 API 用 API；RPA 只用于没有 API 的场景，且做成人机协同（用贵司自己的账号登录态、限速运行），不做无人值守爬虫。卓创行情那条走的也是「官方导出文件导入」，不是高频抓取。

「ERP 也能算，关键是结合最小起订量」「流程图要细到每个岗位干什么」「以前做了导入功能没人用」

运算范围：销售／生产计划输入（保留手工经验录入 ＋ Excel 导入两条路，不强制打通销售预测，与会上共识一致）→ BOM 展开 → 扣库存与在途 → 按最小起订量与包装倍数圆整（贵司例：共母算出 5 公斤、按 10 公斤起订、按倍数采买）→ 需求／供应／累计缺口网格 → 一键转请购。

落地保障——针对「以前做了没人用」：开发前输出分岗位细化流程图（计控、采购、仓储每个人在哪一步做什么），与计控、采购的一线使用者现场确认后才开工；UAT 由同一批人验收。流程图会审是硬前置，先让用的人认可，再写代码。

「ERP 份额分配按单个物料太死……我想按当月整批总额 60/40 分，小物料整单给一家」「让他把清单列详细」

这正是场景 4 要解决的。底座标准已含：配额支持份额／绝对量两种口径、强弱管控档位、单月上限。场景 4 在此之上开发贵司要的规则：低于阈值的小额物料不拆单、整单派给一家，按月度总额平衡两家份额；并联动签样——A、B 供应商打样签字确认后，订单组只在已签样供应商中分配。

为什么不在 ERP 做：下单入口在 SRM，配额校验必须贴着下单动作；放 ERP 等于两头开发、两头对接，正是会上说的「做重复事情」。

「OA 里现在也有打样流程和报表，7 万多贵」「但 OA 一单一张，190 克瓶三轮中试全靠手工记」「我建议还是在 SRM 里搞」

1. OA 能干的，我们帮贵司先配起来（不收费）：现有 OA 流程加每日定时催办推送——会上已确认这是配置问题，不是开发问题。
2. OA 结构上做不了的四样（会上逐条对过）：多轮次挂同一需求 ID（三轮中试不再靠手工记录）；小试→中试→批试连贯状态机与研发／生产／质量三方会签；供应商门户打样任务下发与进度可见；节点计时卡点看板（「上机测试 116 小时」这类卡点自动浮出）。
3. 支持分步上：一期先上状态机＋多轮挂 ID＋计时看板＋催办；门户下发与电子签联动放二期。先跑顺再扩，避免一次上满没人用。价格随整包与分期谈。

「仓库收货还是在 ERP 操作就好了，不要让他在 SRM 搞来搞去」

仓库人员只做一个动作：拿 PDA 扫送货单／箱标（这一步在 SRM 侧，因为码是 SRM 生成的），扫完数据自动推送 ERP 生成待检验收货单，后续入库照旧在 ERP。不存在两套录入、不用进 SRM 菜单。

「接口只有这么几个吗？不可能吧」

标准接口表是按业务对象归并的——一行「主数据同步」背后是物料、供应商、组织、银行账户等多个接口。会后输出逐接口明细清单（含方向、字段、触发时机），供贵司接口负责人核对补漏。

「买硬件我们都不出费用的，谁要谁出钱」

与报价口径一致：平板、PDA、标签打印机不在报价内，由使用部门（品控／仓储）自行采购；我们提供选型建议并负责到货后的联调。唯一提醒：场景 7、8 的验收依赖硬件 11 月底前到位。

贵司文档要求「微服务架构、MySQL／Oracle／SQL Server 数据库」（6.1 节）。

大白话解释一下：「微服务」是把一套系统拆成几十个小服务分开跑，适合几百人的研发团队协作，代价是服务器要更多台、中间件要装一堆、日常运维要专人盯——这些成本上线后都落在贵司自己头上。

我们的系统是 Java 开发的一体化架构，数据库用 PostgreSQL（和 MySQL 一样的主流开源数据库，只是没写进贵司文档的括号举例里）。贵司文档自己定的性能指标是「200 人同时在线、峰值每秒 300 次请求」——一体化架构跑这个规模绰绰有余，而且部署在贵司自己服务器上，越简单越好维护。源码全部交付，将来怎么改都透明。

建议：验收看实打实的性能指标（多少人在线、响应多快、可用率多少），不纠结架构名词；这条差异我们会写进书面应答里，不藏着。

贵司文档里两处说法相反：一处写「订单在 ERP 生成、同步给 SRM 展示」（URS-069），另一处写「订单以 SRM 为准、账务库存以 ERP 回执为准」（7.2.1 权威矩阵）。

说白了就一个问题：采购员到底在哪个系统里下单？在 ERP 下、SRM 只看，还是在 SRM 下、回传 ERP 记账——两种我们都能做，但方向不定，后面的开发没法动手。

这正是我们排期里 9/25 前要贵司拍板的第一件大事。建议会上就定，或者定一个负责拍板的人和时间。

贵司文档要求「飞书统一请购入口」，同时要求「过渡期 OA 和飞书并行，但同一件事只能有一个地方审批算数」（URS-014/015/017、7.2.2 第 7 条）。

这个要求我们认，而且写得很对——怕的就是两边都能提单、两边都在批，最后重复下单没人发现。并行期怎么防重复、什么时候彻底切换到飞书，我们在蓝图阶段给出书面方案。

这是 9/25 前要拍板的第二件大事（请购入口定在哪）。

贵司文档要求 PDA「断网时数据缓存、联网后自动补传」，并列为必须做（URS-089、6.2 断网容错）。

先说难点在哪：断网时两台扫码枪各扫了同一批货，恢复联网后以谁为准？这个规则不先定好，做出来就是乱账——重复收货比收不了货更麻烦。

建议分两步：第一期做「断网短暂重试 ＋ 本机暂存草稿」（覆盖网络抖动这类常见情况）；完整的离线收货模式放第二期，把冲突规则定清楚了再做。不是不做，是先定规则再做——这条希望会上定个档。

贵司文档要求消息通知支持「飞书／邮件／短信」三种（URS-012）。

飞书和邮件已含。短信要另买第三方短信包（按条收费，费用不高但是持续性支出），而供应商基本都在飞书群或门户里能收到通知。

请贵司确认：短信是真需要（比如给不用飞书的供应商发对账提醒），还是文档里顺手写上的——真要就列进范围，不要就省一笔。

贵司文档写「供应商（我们）采购、部署并报价」（7.5 节），会上说的是「谁用谁出钱、贵司自购」。两个口径打架了。

两种我们都支持，定一个就行：

• 我们代买：更新版报价里单列设备费，品牌、规格、质保写清楚，不加价；
• 贵司自购：我们出选型清单（收货用工业安卓 PDA、录入用平板），到货后负责调通。

提醒一句：不管谁买，品控和仓储那两个场景的验收依赖硬件 11 月底前到位。