AADE MyData项目：发票修改机制的技术解析

AADE MyData项目：发票修改机制的技术解析

aade-mydata Interface for ΑΑΔΕ myDATA invoicing REST API. It handles almost all the boilerplate code for sending, cancelling and requesting invoices. 项目地址: https://gitcode.com/gh_mirrors/aa/aade-mydata

在希腊财税系统AADE MyData项目中，发票的修改机制是一个重要但容易被误解的功能。本文将深入解析发票修改的技术实现原理，帮助开发者正确理解和使用该功能。

发票修改的核心机制

当通过SendInvoices接口提交发票后，系统会返回三个关键标识：

• invoiceUid：发票的唯一标识符
• invoiceMark：发票的验证标记
• qrUrl：发票二维码链接

关键发现：每次传输（包括修改）都会生成新的invoiceMark，但invoiceUid可能保持不变。这是判断发票是否被修改的核心依据。

发票UID的生成规则

发票UID是通过SHA-1哈希算法生成的，计算基于以下字段：

1. 发行方VAT号码
2. 发行日期
3. 财税登记分支机构编号
4. 发票类型
5. 发票系列
6. 序列号
7. 发票偏差类型（如存在）

修改与新建的判定标准

• 修改发票：保持上述所有字段不变，仅修改其他字段（如金额）。系统会保留相同UID，生成新Mark，视为原发票的更新版本。
• 新建发票：改变任一UID计算字段，系统会生成全新UID和Mark，视为独立新发票。

实践建议

1. 如需修改发票内容，确保不更改影响UID计算的字段
2. 通过比较UID值判断操作结果：
   • UID不变 → 修改成功
   • 新UID → 新建了发票
3. 系统会自动以最后一次有效传输为准，之前版本将被忽略

技术实现要点

该机制的设计体现了希腊财税系统的几个特点：

1. 审计追踪：通过不断变化的Mark记录每次传输
2. 数据一致性：UID作为业务主键确保核心信息稳定
3. 操作幂等性：相同内容的多次传输不会产生重复记录

理解这些机制对于开发与AADE MyData集成的系统至关重要，可以避免常见的发票管理错误，确保财税合规性。

aade-mydata Interface for ΑΑΔΕ myDATA invoicing REST API. It handles almost all the boilerplate code for sending, cancelling and requesting invoices. 项目地址: https://gitcode.com/gh_mirrors/aa/aade-mydata