五、支付方式与定价专题对照(本场景重点)
经销商下单时的支付方式 + 备件定价——Pentana 与新链路在表达模型上的根本差异,以及逐项映射建议与开发优化项。含 5.1-5.4 支付方式/发票职责、5.5-5.7 定价专题(订单类型驱动价格、软件订单备件定价、经销商买价 vs 终端车主买价)。
5.1 表达模型差异
Pentana:无支付方式枚举,三层客户主数据隐式表达 单系统
Pentana 在下单(OE202)时没有"现金/EFT/信用卡/COD"枚举式支付方式下拉框。"结算类型"由 AR402 客户主数据三层字段决定:
① Account Type 二选一(结算类型本质):Open Item(逐票核销,每张发票单独追踪,AR204 用 Apply to Document) / Balance Brought Forward(余额按账龄桶滚存,AR204 用 Apply to Customer);
② Terms Code(付款条件码,如 A001,定义付款天数 7天/30天/月结,驱动账龄);
③ Sales Type(R零售/W批发,是定价渠道维度,非支付方式);
④ Settlement Allowance(早结折扣让利,非支付方式)。
真正的支付工具(支票/EFT/现金)不在 OE202 选,而是在 AR204 收款录入时定(Cheque/Receipt# + Bank + Drawer 字段)。
新链路:下单即选 PaymentMethodEnum + PaymentTerm→ZTERM 枚举化
新链路下单时直接选 PaymentMethodEnum(8 种):T(电汇)/O(赊销 OA)/D(定金)/P(余额)/G(担保)/F(铺货)/L(信用证)/B(保证金);PaymentTerm 标准化映射 SAP ZTERM(order-tool 配置:1/2/4→CB00,250→Z001,200→S001…)。配置入口 PoConfiguration(非客户主数据)。
5.2 逐项映射建议
⚠️ 市场发布状态(业务澄清):PaymentMethodEnum 与 PaymentTerm→ZTERM 映射目前只有 EU 市场上线,EM(澳洲)市场尚未发布。代码里枚举存在,但 EM 业务上未启用。若澳洲要上,需 EM 市场整体切换 + 已上线子公司培训 + 历史数据修复。下表为 EU 已验证逻辑,EM 切换时参照。
| Pentana 概念 | 新链路 PaymentMethodEnum | 映射说明与风险 |
|---|
| Open Item + Terms Code(赊销月结,逐票核销) | O = OA(赊销) | OA 对应赊销;但 Pentana 的 Open Item(逐票)vs Balance Forward(滚存)二分法在新链路无直接对应——需确认 SAP 侧如何承接(疑似 SAP 客户主数据 accounting group 区分) |
| Balance Brought Forward(余额滚存账龄桶) | O = OA(赊销) | 同为赊销;核销方式(逐票 vs 滚存)差异需 SAP 侧配置承接 |
| AR204 即时收款(支票/EFT/现金,录 Cheque#+Bank) | T = T/T(电汇) | T 对应电汇;现金/支票在 PaymentMethodEnum 无直接枚举——疑似走 T 或由 SAP 侧承接,需确认 |
| 定金 | D = Deposit | ✅ 直接对应 |
| 信用证(LC) | L = LC | ✅ 直接对应(多用于国际) |
| Terms Code(付款天数 7/30/月结) | PaymentTerm→ZTERM | PaymentTerm 映射 ZTERM 已在 order-tool 配置;Pentana Terms Code(如 A001)→PaymentTerm code→ZTERM 的完整映射表需补 |
| Sales Type(R零售/W批发) | 无直接对应 | Sales Type 是定价渠道维度,非支付方式;新链路定价走商品中心/价格规则,不靠 Sales Type |
| Settlement Allowance(早结折扣) | 无直接对应 | 早结折扣让利;需确认 SAP 侧折扣/返利配置承接 |
5.3 信用控制对照(本场景另一重点)
信用池(信用额度控制):新开发项,非 SAP 承接 🟡 新开发 + 业务打合
Pentana:AR402 Screen 6 Credit Details 维护信用额度;下单触发信用检查,失败→HE201 Type 03 信用审批→OE215 释放信用冻结。账龄:AR602 Accounts Debtor Enquiry 按 customer balance 看账龄汇总/月结单/付款历史(Open-item 逐票 / balance-forward 按桶)。
新链路(业务澄清):信用池(信用额度控制)是上了 PaymentMethodEnum 字段后需要配套的新开发项,不是 SAP 侧承接。EU 市场正在开发信用池逻辑,需与业务打合 EU 正在开发的逻辑是否符合业务想要的;如果符合,EM(澳洲)市场也要有开发和测试周期。目前代码里 creditLimit/aging 无业务命中,证实是待开发项。
风险:EM 市场在支付方式字段+信用池上线前,赊销(OA)客户下单无额度闸门→坏账风险;与 PaymentMethodEnum 字段发布节奏联动,不能分开上线。这是本场景最大交付风险——涉及业务打合+EM 开发测试,时间不确定。
⚠️ 经销商确认付款未实现:POTD handleDealerConfirmPayment(SubsidiarySalesOrderServiceImpl:1176-1186)是 TODO 桩,仅记日志返回 true,注释"TODO: 保存附件信息到订单中心"。对照 Pentana AR204 完整收款录入(Cheque#/Bank/Drawer/核销目标)。需确认经销商侧收款是否由 SAP 侧承接,或需开发补齐。
5.4 发票职责迁移(本场景另一重点,联动场景4)
发票职责从 Pentana 内部自持 → SAP 外部持有 🟢 职责迁移点(文档必讲)
Pentana 自持 AR、自己开票,内部 GL 闭环:经销商门店下单后,发票由 Pentana 系统自己开——OE212 To Be Charged Run(批量开票,核心)/ OE225 跨仓发票打印 / OE06 即开权限;订单 OE204 放行后 OE212 批量开票,状态置 invoiced。经销商不能自助开票(DC 门户只有下单 DC201/202、退货申请 DC203、回购 DC206、重打印 DC222,无开票 T-Code)——开票在子公司 AR 人员侧。AR 持应收→AR204 收款→GL Interface 内部总账。无任何 SAP/外部财务对接。
iParts 无任何财务能力,发票全推 SAP:销售单确认后 order-tool 推 SAP 销售订单 ZSDI003_OTD_SALES_ORDER + 发票 ZSDI_OTD_FPXX,支持发票回查 ZSD_INVOICE_QUERY(走 SAP 文件下载);AR 应收/收款/GL 全在 SAP 侧。
迁移含义:正向发票职责从 Pentana 内部迁到 SAP。子公司 AR 人员原来在 Pentana 跑 OE212 批量开票,迁移后变成 SAP 自动开票(order-tool 推送触发)、AR 人员在 SAP 侧对账;经销商原在 DC 门户重打印发票(DC222),迁移后发票来源是 SAP。联动场景4:退货红冲(credit note)同样职责迁移——Pentana OE216/OE217 自己开打印 credit note → iParts 推 SAP 红冲 INVCAT=TI。
✅ 职责迁移链(四场景统一视角):Pentana 自持 AR/AP(开票 OE212/OE225、credit note OE216/OE217、收款 AR204、付款 AP217、内部 GL Interface)→ iParts 无财务能力,正向发票/红冲/AR/AP/收款/付款/GL 全推 SAP。场景3=正向发票职责迁移,场景4=红冲职责迁移,场景1/2=AP 应付职责迁移。
5.5 订单类型驱动价格对照(本场景重点,需开发优化)
Pentana:Sales Type 直接驱动价格(IC407 折扣矩阵) 单系统
Pentana IC407 折扣矩阵按 (Sales Type + 客户折扣码[AR402] + 物料折扣码[IC404]) 三键查折扣,手册原文明示"允许为不同 sales types 配不同价",举例 Daily 单 20% / Stock 单 30%。基础价 IC404 维护 Prices 1-6(List/Trade/Daily/Stock/Internal/Special Wholesale)+ RRP。Sales Type 取值=订单类型(Stock/Daily/VOR)+ 渠道(R/W),订单类型直接驱动差异化定价。
iParts:有 Urgent/Regular/VOR 维度,但只"半进"算价 🟡 需开发优化
iParts 有紧急度维度 PoConfigurationPoTypeEnum(Regular=1/Urgent=2/VOR=3),独立于 OrderTypeEnum(LOCAL/INTERNAL)、独立于 PartPriceOrderTypeEnum(ZB01/ZF01/MSRP)。但:
① 基础价完全解耦——changeApiOrderType 对 orderCategory=1/2/3 原样返回 ZB01,Regular/Urgent/VOR 拿同一份基础价;商品中心 b_spare_part_price 价表无 order_type/紧急度列。
② 折扣进了但有 conflation 雷点——price-center 把 orderCategory 原样塞进折扣查询 orderType(OrderPriceCalculateCmdExe:177),mapper AND order_type=#{orderType},理论上 Urgent/VOR 能匹配不同折扣行;但 b_spare_part_discount.order_type 这一个 Integer 列被双重语义占用(紧急度 1/2/3 vs SAP AUART 1=ZB01),值 1 恰好两边对齐、2/3 无对应 AUART——复用时最大语义陷阱。
③ 字段滥用:orderCategory 一个 Integer 字段同时塞紧急度(1/2/3)和算价口径(5/6/7 免费/软件/零售)。
📌 对应关系(业务澄清,命名反向易混):Pentana Stock(正常备货)→ iParts Regular(1);Pentana Daily(日常加急)→ iParts Urgent(2);Pentana VOR → iParts VOR(3)。⚠️ 不要按字面把 Daily→Regular、Stock→Urgent——Pentana "Daily" 听似常规实为加急,"Stock" 听似库存实为正常备货。
| Pentana Sales Type | iParts PoConfigurationPoTypeEnum | orderCategory |
|---|
| Stock 正常备货 | Regular 常规 | 1 |
| Daily 日常(加急) | Urgent 加急 | 2 |
| VOR 车在路边 | VOR 超紧急 | 3 |
优化方案:按 Urgent/Regular/VOR 差异化定价需三侧改 🟢 开发项(非配置)
商品中心(product-center):① b_spare_part_price 加 sales_type/urgency_type 列(基础价按紧急度差异化,优先匹配专用价、兜底通用价);② b_spare_part_discount 加独立 urgency_type 列,把紧急度从被滥用的 order_type 列拆出来(不破坏现有 AUART 折扣数据)。
订单中台 price-center:① OrderDTO 加独立 urgencyType 字段(从 orderCategory 拆出,别再共用);② SparePartPriceQuery/SparePartDiscountQuery 透传 urgencyType;③ changeApiOrderType 对 1/2/3 派生区分(或走 salesType 列不动 apiCode)。
新POTD:PartsHubPoAssemblerImpl 在 setOrderCategory 之外 setUrgencyType(来自 PoConfigurationPoTypeEnum 的 1/2/3)。
SAP:若走新 AUART(给 Urgent/VOR 新增 ZB02/ZB03)则 SAP 侧配对应价表;若走 salesType 列方案则 SAP 不动。
折扣链路基本现成可复用(改动小),基础价链路必须新增列+改派生(改动大)。优先治理 orderCategory/order_type conflation,再做基础价差异化。
5.6 软件订单备件定价对照
Pentana:无"软件订单"类型,软件=非库存杂项物料 单系统
Pentana 没有"软件订单"类型。软件(软件升级 GLDSSFT/诊断授权 DIAGLI/维修信息访问 REPINF/SERVICE PLAN)以 Sundry Item 非库存杂项物料形式处理,OE406 维护,每仓库一个平价,不走 IC407 折扣矩阵(无物料折扣码),订单行/索赔行手工输入或自动带出。采购侧 PN202/PN406/PN802 非库存采购(含软件订阅采购)。
iParts:有"软件订单"分类,但用普通 B2B 的 DNP 价,无独立软件价表 🟡 需业务确认
iParts 有软件订单分类 orderCategory=6, ZBDR(PotdPriceCalCulateOrderCategoryEnum.SOFTWARE)+ OrderPoTypeEnum.SOFTWARE。但商品中心 b_spare_part_price SQL 不带 orderType 过滤,ZBDR 走非零售分支,与 ZB01(LOCAL)用同一张价表、同一 groupCode、同一 DNP 单价。软件差异仅在:① SAP 税率请求 orderType=ZBDR(可能不同税率);② 折扣查询 orderType=6(若 b_spare_part_discount 配了 orderType=6 折扣则生效,否则无折扣)。没有"软件备件"特殊行类型参与定价——软件备件单价=普通 B2B DNP 单价;软件特殊性体现在 SAP 单据类型 ZBDR(税率/账务)+ 可选 orderType=6 折扣配置,不在备件基础价上。
对照结论:两侧都没有软件专属备件价表。Pentana 把软件当杂项物料(平价、不进折扣矩阵);iParts 把软件当独立订单分类(走 DNP 价、SAP ZBDR 单据类型、可选 orderType=6 折扣)。iParts 比 Pentana 多了 SAP 单据类型层面的软件区分(ZBDR 税率/账务),但基础价层面两者都不给软件独立价。若业务要软件备件独立定价,iParts 需给 b_spare_part_price 增加 orderType 维度或为 ZBDR 单独配客户组/价表(同 5.5 优化路径)。
5.7 经销商买价(B2B)vs 终端车主买价(零售)对照
| 维度 | B2B 子公司销售(经销商向子公司买) | 门店零售(门店向车主卖) |
|---|
| 派生 orderType | LOCAL(经销商DEALER买+子公司SUBSIDIARY卖) | RETAIL(orderCategory=7,卖方=STORES门店) |
| apiCode | ZB01 | MSRP |
| 价源 | 商品中心 b_spare_part_price,客户组 MSS-NSC 或 NSC-Dealer | 商品中心 b_spare_part_price,客户组 Dealer-Customer |
| 价格性质 | DNP(经销商买价/分销价) | MSRP(建议零售价/终端车主价) |
| 折扣 | b_spare_part_discount(orderType+卖方+买方+门店),type/num/part 三级折扣累乘 | 不走订单级折扣;零售用商品行自带 discountRate |
| POTD 入口 | SubsidiaryCompanySalesOrderController /web/subsidiary/sales-order | WorkshopSalesOrder/StoreSalesOrder(门店零售单,POTD 另一套) |
✅ 两侧都区分经销商买价 vs 终端车主买价:Pentana IC404 价格层级含批发层(Prices 2-6)+ 零售层(RRP),折扣类型 1=Wholesale/R=Retail,Sales Type R/W 渠道切分;iParts 用 groupCode(买卖方关系派生)区分 DNP vs MSRP 两套价表。差异:iParts 零售走 MSRP + 行级 discountRate(不走订单级折扣),Pentana 零售也进 IC407 矩阵。