销项管理 / 开票申请单
开票申请单
系统发起提到一期（2026-08-13）：游戏结算后台推送的就是本次要迁移的开票申请流程，
流程迁到平台后其推送目标必须改，因此平台一期必须提供对外发起流程接口（设计 2.3）。
列表新增「来源」列区分手工 / 系统发起；系统发起的单据不经草稿态，接口受理成功即进入审批中。
（CRM 推的是另一条独立的 CRM 开票流程，本期不涉及。）
| 申请单号 | 业务线 | 受票方名称 | 申请公司（我方主体） | 开票金额 | 发票类型 | 状态 | 来源 | 申请人 | 提交时间 | 操作 |
|---|
‹12
3…13›
红字管理 / 红字申请
红字申请
| 红字申请单号 | 业务场景 | 原蓝票号码 | 我方主体 | 红冲方式 | 冲红原因 | 本次冲红金额 | 状态 | 申请人 | 申请时间 | 操作 |
|---|
‹12›
发票数据 / 发票列表
发票列表
线下开票已确认纳入台账（2026-08-13，原 Q16 关闭）：口径统一为——只要是公司开出去的票据，
含通用形式发票 / 收据 / 境外形式发票，一律沉淀进发票数据台账，保证"公司开出的票"完整可对账。
线下票的差异仅在于：无德勤回传、开票状态固定「线下已开」、税额取系统计算值；
通用形式发票的发票号码取平台自生成的形式发票号（开票日期+流水号，见 6A.2），收据/境外形式无号显示「—」。
本月开票张数
316
线上（德勤）298 · 线下 18（已入台账）
本月价税合计
￥12,486,900.00
税额 ￥706,428.30
开票中
7
已推德勤、待回传
开票失败 / 待处理
2
需人工介入重推
| 发票号码 | 发票类型 | 开票日期 | 销方（我方主体） | 受票方名称 | 受票方税号 | 金额（不含税） | 税额 | 价税合计 | 开票状态 | 来源申请单号 | 业务线 | 抛证类型 | 中台推送 | 凭证号 | 操作 |
|---|
发票数据由开票申请执行产生：线上类型（电子专/普票）由德勤回传发票号码/代码/税额后回写沉淀；
线下类型（通用形式/收据/境外形式）无德勤回传，发票号码留空、状态记为「线下已开」。
「凭证号」需财务中台回传后回填，一期是否回传待与中台确认。
‹12
3…32›
发票 · 24417000000123456789
蓝字发票支持发起独立红字流程。红字申请需重新经过申请人、直接上级、财务复核、税务复核审批；原蓝票信息将作为快照带入，不能直接修改。
发票信息 德勤回传 · 只读
发票号码24417000000123456789
发票代码144031809110
发票类型电子专用发票
开票方式线上（德勤）
开票日期2026-07-27
开票人德勤开票系统
发票状态已开票
销方信息（我方主体）
销方名称上海宽娱数码科技有限公司
纳税人识别号91310110776333195C
🔒 隐藏字段 不在页面展示 · 系统内部使用
公司编码1001
随我方主体带出 · 推送财务中台时使用
税务经理 AD 域wangdanlei
随我方主体带出 · 用途=抄送
受票方信息 来源客商系统 · 开票时快照
受票方类型公司
受票方名称梦之投集团有限公司
纳税人识别号91110112MA01QAAR1D
受票方地址北京市朝阳区xx路1号
受票方电话010-8888xxxx
开户行 / 账号招商银行北京分行 / 1209 2424 5410 901
电票收票邮箱finance@mztou.com
发票明细行
| 行号 | 开票名称 | 税收编码 | 规格 | 单位 | 数量 | 单价 | 金额 | 税率 | 税额 | 价税合计 | 收入类型 | 抛证类型 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | *信息技术服务*广告推广费 | 3040502000… | — | 次 | 1 | 50,000.00 | 50,000.00 | 6% | 3,000.00 | 53,000.00 | 广告收入 | 当期开票 |
| 2 | *信息技术服务*技术开发费 | 3040301000… | — | 次 | 1 | 25,471.70 | 25,471.70 | 6% | 1,528.30 | 27,000.00 | 技术开发费 | 提前开票 |
系统计算税额￥4,528.30
德勤回传税额￥4,528.30
税金差异￥0.00 差异由财务中台处理
发票备注—
关联与追溯
来源开票申请单
TAX2026072700018
所属开票分组分组 1（共 1 张发票）
业务线 / 详细业务线广告 / 效果预付费
申请人吨吨 · 07-27 10:12
合同号HT-2026-0512 明细行手填
抛证类型
按明细行 行级 · 见明细行表
抛证类型已下移到明细行（2026-08-13），本张发票两行取值不同，
故此处不展示单一值——发票列表该列的展示口径待定（Q26）。
下游账务
德勤开票完成 已回传
推送财务中台 已推送
中台生成凭证 待回传
入金蝶
票—证—账追溯依赖中台回传凭证号与账务信息，一期先沉淀发票侧数据。
配置管理 / 收入类型
收入类型
本页已按 2026-08-13 业务评审重做：原「开票业务类型」主数据方案整体作废（业务方明确不需要，仍希望自己选税收分类编码）。
平台唯一自维护的表单主数据只剩这份收入类型下拉——无外部来源、不走审批，内容即「业务线 ↔ 收入类型」映射表（设计 3.3.1 / 3.5.1）。
| 收入类型编码 | 收入类型名称 | 所属业务线 | 排序 | 状态 | 操作 |
|---|
‹12
3›
维护角色（税务 or 财务运营）待确认（Q22）。启停即时生效，停用后申请人下拉不再出现。
税收分类编码 德勤同步 · 只读
原「新增开票业务类型」页已删除（2026-08-13 方案作废）。税收分类编码来源德勤，
接口 = 接口清单「开票品名接口」（
serviceId=inven_tory_Item，入参为业务线编码如 SL001=游戏，
返回 编码 / 名称 / 税率 / 是否删除 / 税收分类大类）。平台只同步不维护，申请人在明细行直接选择。
取数方式（实时调用 or 定时同步到本地）待研发定（Q9'）。
德勤接口按业务线编码查询
| 税收分类编码 | 编码名称 | 税率 | 税收分类大类 | 免税 | 适用业务线 |
|---|
「免税」列是本次评审后新暴露的缺口：开票业务类型作废后免税判断回到申请人，
需要一份免税编码清单支撑「编码命中→显示是否免税」联动（Q10'）。德勤接口返回字段里没有免税标识，
待确认是找德勤加还是我们自己维护。
开票申请单 · TAX2026072700018
基本信息
业务线广告
详细业务线效果预付费
申请公司（我方主体）上海宽娱数码科技有限公司
来源标识平台自有入口 · 手工发起
外部单据编号—
备注—
🔒 隐藏字段 不在页面展示 · 系统内部使用
公司编码1001
随「申请公司」带出（compCode）· 推送财务中台时使用
税务经理 AD 域wangdanlei
随「申请公司」带出（taxManager）· 用途=抄送，不指派审批人
此区块仅在原型中显示，说明平台取了这些值但不展示给业务；实际页面不渲染。
表头已删除「关联合同履约单」（2026-08-13）；「合同号」在明细行逐行展示，不在表头。
「公司编码」「税务经理」改为隐藏字段，不在表单与详情正文展示。
受票方信息 系统选择 · 来源客商系统 · 只读
受票方类型公司
受票方填写方式系统选择 另有「手工输入」方式
客户名称梦之投集团有限公司
纳税人识别号91110112MA01QAAR1D
受票方地址北京市朝阳区…
受票方电话010-8888xxxx
开户行招商银行北京分行
银行账号1209 2424 5410 901
电票收票邮箱finance@mztou.com
开票内容（按开票分组 / 发票组织）
1开票分组 · 一张发票
电子专用发票
线上（推德勤）
开启（合并推送）
推德勤后已锁定不可改
| 行号 | 税收分类编码 | 编码名称 | 税率 | 收入类型 | 免税 | 开票名称 | 合同号 | 抛证类型* | 数量 | 价税合计 |
|---|---|---|---|---|---|---|---|---|---|---|
| 1 | 3040502000000000000 | 广告服务 | 6% | 广告收入 | 否 | *信息技术服务*广告推广费 | HT-2026-0512 | 1 | ￥53,000.00 | |
| 2 | 3040301000000000000 | 研发和技术服务 | 6% | 技术开发费 | 否 | *信息技术服务*技术开发费 | HT-2026-0512 | 1 | ￥27,000.00 |
抛证类型已下移到明细行（2026-08-13）：当前节点（财务复核）逐行填写。
上例两行取了不同值，正是下移的原因——同一张发票的不同明细行可能落在不同账务场景。
🧾 实际推送德勤的发票行 合并开启
申请单 2 行明细 → 发票 2 行（合并键不同，未发生合并）
| 发票行 | 税收分类编码 | 开票名称 | 税率 | 价税合计 | 德勤回传税额 | 系统计算税额 |
|---|---|---|---|---|---|---|
| 1 | 3040502000000000000 来自明细行 1 |
*信息技术服务*广告推广费 | 6% | ￥53,000.00 | ￥3,000.00 | ￥3,000.00 |
| 2 | 3040301000000000000 来自明细行 2 |
*信息技术服务*技术开发费 | 6% | ￥27,000.00 | ￥1,528.30 | ￥1,528.30 |
本例两行的「税收编码＋开票名称」都不同，即使开关开启也不会合并，
因此发票行与明细行一对一、无需税额分摊。
若两行合并键相同则会合成 1 行推德勤，回传税额需按价税合计占比分摊回明细行（6.2.3）。
合并推送时必须保留「发票行 ↔ 申请单明细行」映射，供回传分摊与推中台反查（T3'）。
系统计算税额与德勤回传不一致时以回传为准，两者一并推中台，差异由中台处理（R6 / 6.2.4）。
本张发票小计：￥80,000.00
· 发票号码：24417000000123456789（德勤已回传）
开票金额总计￥80,000.00
开票分组数1 张发票
抛证类型逐明细行填写（2026-08-13 业务确认，原 Q1 关闭）。
枚举沿用四类；与中台会计引擎的编号对齐、以及中台报文是否支持行级抛证类型待确认（Q2 / Q14）。
审批流
申请人 已提交
直接上级 通过
金额≤50万，走直接上级审批。同意。
财务开票复核 审批中
税务复核
平台对接德勤开票
申请人确认
发起开票申请
本页已按 2026-08-13 业务评审调整：
① 明细行删除「开票业务类型」，改为申请人直接选税收分类编码（来源德勤），税率随编码带出；
② 收入类型、是否免税/免税标志恢复申请人自选；
③ 受票方恢复「手工输入」方式；
④ 抛证类型下移到明细行；
⑤ 删除「关联合同履约单」「销售资源批次」；合同号留明细行手填；
⑥ 版权项目/课程项目/属性不进表单（固定值，仅推凭证）；
⑦ 通用形式发票自动生成形式发票 + 盖章流程（随迁能力）；
⑧ 公司编码、税务经理改为隐藏字段，不在页面展示（见表头最下方虚线框）。
本次补充：⑨ 开票分组新增「明细合并开票」开关（默认开启）——原型此前漏了该字段。 它控制推德勤时是否按「税收编码＋开票名称」把多个明细行合成一个发票行， 并配「推送德勤预览」直接展示"申请单 N 行 → 发票 M 行"与税额分摊试算。 ⚠️ 注意它不是德勤接口的
本次补充：⑨ 开票分组新增「明细合并开票」开关（默认开启）——原型此前漏了该字段。 它控制推德勤时是否按「税收编码＋开票名称」把多个明细行合成一个发票行， 并配「推送德勤预览」直接展示"申请单 N 行 → 发票 M 行"与税额分摊试算。 ⚠️ 注意它不是德勤接口的
isCombine——那个管的是"开几张发票"，我方恒传 1。
基本信息
受票方信息 系统选择（客商系统）/ 手工输入 双方式
开票方式按发票类型给默认值（电子专/普票→线上推德勤；通用形式/收据/境外→线下），允许人工修改。
税收分类编码由申请人自选（来源德勤，按业务线过滤），选中后带出编码名称与税率（只读）；
收入类型按业务线过滤后自选；是否免税仅在编码命中免税清单时可选（恢复原 Flow 联动）。
抛证类型已下移到明细行，在「▾ 更多」里，由财务审批节点填写。
发票类型=通用形式发票时，分组下出现形式发票生成与盖章区（6A）。
「明细合并开票」开关（分组级，默认开启）：
控制推送德勤时是否把本张发票内的明细行按「税收分类编码 ＋ 开票名称」合成一个发票行。
管的是"这张发票上印几行"，不是"开几张发票"——开几张由建几个分组决定。
只影响推德勤的报文，不改申请单数据——明细行始终按业务原样保存，
项目 / 费用承担部门 / 结算期间等账务维度不上发票、只留在平台供推中台使用。
合并后德勤回传的是发票行级税额，平台需按价税合计占比分摊回各明细行（尾差挤金额最大行）；
关闭则逐行推送、回传行税额直接落行、无需分摊。开关下方的「推送德勤预览」实时显示"申请单 N 行 → 发票 M 行"。
⚠️ 不要接到德勤的
开关草稿态与驳回后可改，推送德勤后锁定（分摊结果依赖它），改动留痕。 合并键之外税率不一致时强制不可合并并拦截提交；单位/规格/服务名称不一致取首行值。
⚠️ 不要接到德勤的
isCombine 上：那个字段决定德勤把这次推送开成几张发票
（=0 时按行拆成多张），我方恒传 1，否则会破坏"一个分组=一张发票"。
开关草稿态与驳回后可改，推送德勤后锁定（分摊结果依赖它），改动留痕。 合并键之外税率不一致时强制不可合并并拦截提交；单位/规格/服务名称不一致取首行值。
各分组各明细行价税合计自动汇总
明细行编辑改为右侧抽屉：点行上「✎ 编辑」滑出抽屉，
承载该行全部字段（核心字段/增值税发票字段/通用字段/游戏字段/抛证类型/附件），并按 3.4.1 显隐规则随发票类型与业务线增减。
抽屉顶部箭头可连续切换明细行（跨开票分组也能切，支持 ↑↓ 键与 Esc 关闭），适合逐行录入与检查。
抽屉不遮挡表格，改动实时同步到主表。有折扣时价税合计 = 折扣前价税合计 − 折扣金额。
批量导入：一个 Excel 一次导入「发票分组 + 明细行」——模板用「发票组号」列把明细行归到各张发票下，
导入时按发票组号自动建分组、挂明细，无需先手工建分组。多张发票、多行明细一次搞定。
红字申请 · RINV202608260003
申请信息 审批节点全部只读
业务场景D · 进项发票 · 购方发起
我方主体上海宽娱数码科技有限公司
红冲方式部分红冲
冲红原因销售折让 部分红冲可选
申请人欧必
销方供应商某游戏发行商有限公司 客商主数据
业务线游戏
红字信息表确认单号—（我方发起，推送德勤后回写）
冲红原因说明本次结算金额调整，申请对原进项蓝票进行部分红冲。
原蓝票信息 购方手工录入 · 已上传原票
原蓝票号码24417000000987654321
原蓝票代码144031809110
销方某游戏发行商有限公司
开票日期2026-08-02
价税合计￥120,000.00
受票方邮箱ap@bilibili.com
冲红明细 申请人填写 · 页面金额为正数
| 行号 | 税收分类编码 | 开票名称 | 数量 | 含税单价 | 价税合计 | 德勤匹配结果 |
|---|---|---|---|---|---|---|
| 1 | 3040301000000000000 | *技术服务*游戏服务费 | 1 | ￥20,000.00 | ￥20,000.00 | 匹配成功 |
红字申请金额（含税）￥20,000.00
部分红冲以
reqCategory=70 推送 invoiceDetails，德勤按「税收分类编码 ＋ 开票名称 ＋ 含税单价（±0.01 尾差）」匹配原蓝票行并倒算红字净额、税额；平台不自行计算累计可冲余额，最终以德勤校验为准。红字发票信息确认单
确认单状态02 销方录入待购方确认
确认单编号!CR202608260019
最后查询时间2026-08-31 18:20
红票状态待收对方红票
平台定时查询
t_tms_dr_invoice_rev_con_h.CONFIRM_STATUS（编码 01—08），只轮询 02、03；01、04 为确认成功，05—08 为终止。确认成功后自动进入红票查询集合，无需人工登记红票。一张申请对应一张确认单，按单条关联。红票结果 确认单表查询 · 只读
查询状态待查到红票
红票号码—
红票开具日期—
红票价税合计—
红票代码—
红票文件—查到后提供 PDF / OFD / XML 下载
票面结果查
进项侧还可用
t_tms_dr_invoice_rev_con_h：REV_INVOICE_NUMBER、REV_BILLING_DATE、AMOUNT_TAX、TOTAL_AMOUNT、TOTAL_TAX。红票代码与文件按场景补查：销项（A/B）用 TMS_VAT_DR_INV_POL_HID 关联 t_tms_vat_dr_inv_pol_h，取 INVOICE_CODE、LOCAL_URL、PDF_URL、OFD_URL、XML_URL；进项（C/D，本单）用 TMS_VAT_CR_INV_POL_HID 关联 t_tms_vat_cr_inv_pol_h，取 INVOICE_CODE、LOCAL_URL、PDF_FILE、OFD_URL、XML_URL。两表文件字段命名不同，按表区分取值。进项侧还可用
REV_INVOICE_NUMBER = INVOICE_NUMBER（两侧均有索引）作为校验路径；该字段有值即说明红票已开具。红字审批流
申请人 已提交
直接上级 通过
财务复核 通过
平台提交德勤 提交失败
审批意见（德勤返回原文）
code=400：未匹配到具体明细行（红冲数量大于原蓝字发票数量），请修正冲红明细后重新提交。
code=400：未匹配到具体明细行（红冲数量大于原蓝字发票数量），请修正冲红明细后重新提交。
申请人修正后重新提交 已提交
税务复核 审批中
平台提交德勤红字申请
等待对方开具红票
德勤报错原文直接展示，不做话术转换：即使较长或含技术信息也原样写入对应节点的审批意见，避免转换过程丢失定位线索；申请人据此修正明细并重新提交，按 Flow 配置重新审批。