⑦ 下单(开票信息预下单)

POST  https://openapi.kailingteck.com/api/v1/icbc/order/pre
工行:/ui/jft/ui/invoice/pre/order/V1  (页面类 · RSA2 签名 · biz_content=JSON)

鉴权:X-App-Key + X-Sign + X-Timestamp。中台注入 appId、invoiceNotifyUrl、verifiedCode、ukeyId,其余业务字段全字段原样透传给工行,不筛不改。

• taxPaymentMethod=1 或不传 —— 企业委托扣缴(默认)。付款成功后工行自动开票 + 代扣代缴 + 把钱打给散户。
• taxPaymentMethod=0 —— 自然人自行办理。工行不代扣,税由散户本人去办,企业只付货款。仅再生资源场景需要上送,其他场景不用传。

配套字段:iitProject(个人所得税项目)、supplementaryTax(补缴税费标志)。缴税结果可在每日缴税对账单里按「缴纳方式」字段核对。

specificElements(特定要素)与 buyerInvTypeCode(收购发票类型代码)是一组,填错会被税局侧退回:

农产品收购    specificElements = 16    buyerInvTypeCode = 01
报废产品收购  specificElements = 24    buyerInvTypeCode = 04

走业务层 /api/v1/rinv/invoice/create 时,只传其中一个,另一个会按上表自动推导;两个都不传按报废产品收购处理(2026-09-15 按客户确认由农产品改为报废)。原子层不做推导,传什么就是什么。

算税靠工行/税局:你把 taxRate(税率)、mergedCode(税收分类编码)、金额传对,工行按乐企规则算税,税额从预查询(⑩)取回。中台不自算。

不动产、建筑服务、机动车等其它特定要素的字段,工行同样按 specificElements 取值追加,透传层一律原样转发。

{ "code":"CYT_00000", "data":{ "pageUrl":"https://…/redirect/xxx", "mock":false } }

前端 location.href = data.pageUrl。工行页面三种走向(视特定要素/是否实名签/是否换开):

• 农产品收购且不需实名签 → 「订单已受理」页,返回按钮跳 payJumpUrl;
• 农产品收购且需实名签 → 自动提交表单,打开支付页;
• isChange=01 换开 → 「换开已受理」页,返回按钮跳 payJumpUrl。

areaCode(区域代码)与 shouldTaxLocation(应税行为发生地)都填这张表里的 11 位代码。 注意这套代码不等于国标行政区划代码,不能按「重庆=50」去推,必须查表。

这是网关层的返回码,与业务是否成功是两回事——业务校验不通过时工行会在页面上给出中文提示,不走这张表。

工行原文特别注意:返回 -500041、-500042 或其他未知异常时,切勿重复提交, 应先调对应的查询接口确认最新状态再做处理。

• 规格已核实到官方原文:本页「必输 / 最大长度」逐行取自工行《融e聚开票信息预下单接口V1 1.0.11》第 3、4 节规格表。此前该表缺页、只能从示例反推,现已补齐。
• 公对公结算正向开票另有一套参数:payChannel=04 时需上送 invoiceNormal 节点(文档 4.2~4.7 节,含商品明细、车牌号集合、建筑服务明细、旅客运输明细等嵌套结构)。透传层原样转发,本页暂未展开,需要时找我们要。