Trazer o que você já tem

向您的会计索取最近十二个月的进项 XML 文件夹——它确实存在，而且就是会计记账用的那一份。一次性全部上传，先审核供应商选项卡（它最小、也最有复用价值），批量批准后再处理产品。

读取文件产生的是“提案”，而提案不是档案：它不会出现在任何搜索中，不进入报表，也不能用于记账。当您批准时，档案会通过与手工录入相同的路径、相同的校验来创建。因此，一个有问题的 XML 只会变成一个被拒绝的提案，而不会变成您数据库里一个有问题的供应商。

每个提案都有一个键：供应商用 CNPJ，产品用开票方的产品编码。同一个文件夹上传两次也不会产生重复——第二次读取会识别已提议的内容，不会新建行。否则，首次导入一整年的发票就会产生成千上万条重复记录，事后清理的成本比从头录入还高。

它不读取 SPED，也不计算库存或现金的期初余额。SPED 走的是另一条路：其格式每年都会变化，每个区块的含义取决于公司的税制，因此只读一半会得出一个看似正确、实则错误的余额。电子表格映射仍通过各档案页面上现有的导入路径进行。

SPED 读取器导入的是“主数据”：参与方会变成供应商提案，明细项会变成产品提案，并使用与 XML 相同的去重键（证件号和编码），因此同一供应商不会导入两次。余额、税款计算和抵扣额被有意排除在外：SPED 的格式每个日历年都会变化，各区块的含义取决于税制，因此部分读取会得出一个看似正确、实则错误的期初余额——核对能对上，数字却是错的。主数据就是名称、证件号和描述：如果有问题，您一眼就能看出来。如果文件采用的是该读取器不认识的格式，它会拒绝并说明收到的是哪种格式，而不是硬着头皮读取。

直接取自 XML 本身，不做任何解读：供应商取自发票的开票方（CNPJ、法定名称、州）；产品取自每个明细行（编码、描述、NCM、单位）；应付金额取自发票总额。由于 XML 有模式定义，读取是确定性的——这里没有人工智能去猜字段，这是有意为之：猜错 CNPJ 比不读这张发票更糟。