国家
马来西亚
文章类型
平台解读
最后核查
2026-08-30
常见的集成误区，是把 Submit Documents 的响应当成流程终点。MyInvois 明确区分初始受理和完整校验：成功提交返回 HTTP 202 和相关标识，但单据仍可能处于 Submitted，之后才会变成 Valid 或 Invalid。
平台专题 · MyInvois
MyInvois 处理机制
假设 SAP Billing 已过账，并转换为 MyInvois 要求的 JSON 或 XML。传输前，企业就应确定开票纳税人、买方身份、单据类型、税务处理、金额以及原单引用。MyInvois 不会替代这些业务判断。
Submit Documents 先执行结构和提交方检查。通过初始门禁的单据会获得 submission UID 和后续处理所需的单据标识；之所以返回 HTTP 202，正是因为完整校验尚未结束。
随后，集成按照受控频率调用 Get Submission。财务人员应该看到转换后的业务状态，而不是原始 HTTP 代码；源发票必须始终关联 MyInvois UUID、提交引用和校验证据。
本节参考: MyInvois 提交单据 API · MyInvois 查询提交 API · MyInvois 集成实践
五个主要处理阶段
可以提交
业务事实和单据版本选择已经完整。身份、金额或原单关系缺失时，应在传输前阻断。
进入处理
MyInvois 返回 HTTP 202、submission UID，以及初步受理或拒绝的单据。这代表传输进展，不是最终法定状态。
完成校验
通过轮询，每张单据最终进入 Valid 或 Invalid。无效详情应连同原始平台响应送达责任团队。
客户与 ERP 对齐
平台有效单据、客户可阅读版本和 ERP 单据建立关联。平台 Valid 并不能自动证明客户已收到或账务已经对账。
调整并关闭
取消、买方拒绝请求、贷项、借项或退款单据保留与原发票的关系，并进入完成对账的终态。
本节参考: MyInvois 提交单据 API · MyInvois 查询提交 API · MyInvois 集成实践
主要状态及其运营含义
Submitted
完整校验仍在运行。
按建议继续查询，不要无控制地重复提交。
Valid
单据已经通过 MyInvois 校验。
保存标识和校验链接，完成客户交付并同步 ERP 状态。
Invalid
至少一个校验步骤失败。
读取详细错误，更正权威源数据或批准的映射，再判断是否需要重新提交。
Cancelled
开票方通过允许的流程取消了原有效单据。
保留被取消单据及原因，不覆盖原始历史。
受控的 SAP/ERP 至 MyInvois 架构
只有业务事实、提交状态与财务证据从源发票一直连接到后续更正，集成才算完整。
权威发票事实
从受治理的 SAP/ERP 来源读取已批准的客户、供应商、税务、金额、币种、分类及原单引用。
确定性转换
每个业务场景只映射到一个单据类型和版本；关键事实缺失时阻断，不静默替代税号、分类或引用。
提交与幂等
建立稳定业务键，防止重复提交，保留实际出站报文，并区分安全重试与新的法律单据。
状态与异常工作台
轮询最终状态，将校验明细分派给责任人，控制撤销窗口，并阻止无效单据被标记完成。
对账与归档
把 ERP 单据与 MyInvois UUID、状态历史、客户呈现文件、贷借项更正及期间关账对账关联起来。
常见控制缺陷
把 HTTP 成功当成财务状态
这会隐藏从提交到最终校验之间的阶段，让未完成发票看起来已经结束。
不查状态就直接重试
MyInvois 会识别相同报送，并可能返回重复或限流结果。应先查询，再按幂等规则决定重试。
归档时只保存客户 PDF
证据链还要包括源业务事实、结构化报文、MyInvois 响应、平台标识、最终状态和后续调整。
常见问题
为什么 HTTP 202 不是流程终点？
它只表示提交请求已被接收并等待处理，单据最终是否有效需要从后续提交结果和单据状态中取得。
重试应如何处理？
应依据原业务键和已记录的平台响应判断继续查询、安全重试或创建更正；盲目重提可能形成重复单据。
SAP/ERP 至少应保存什么？
业务身份、出站报文引用、submission UID、已生成的 document UUID、校验状态、时间戳、错误及更正关系。
何时可以向客户发布单据？
发布点应按适用场景和最终平台状态形成正式政策，不能仅以传输受理作为依据。
集成控制要求
集成方案应向财务人员提供当前发票状态、后续责任动作，以及从 ERP 过账到平台结果和客户单据的完整审计链路。这些控制要求与技术连通性同等重要。
官方来源
最后核查: 2026-08-30