Trazer o que você já tem

会計士に過去12か月分の受領XMLのフォルダーを依頼してください。それは存在し、会計士が記帳に使っているものと同じです。すべてを一度にアップロードし、まず仕入先タブを確認し（最も小さく、最も活用できます）、一括承認してから製品に進んでください。

ファイルを読み込むと「提案」が作成されます。提案はマスタ登録ではありません。どの検索にも表示されず、レポートにも入らず、仕訳にも使えません。承認すると、手で登録するのと同じ経路、同じ検証でマスタが作成されます。だからこそ、不正なXMLはデータベース内の不正な仕入先ではなく、却下された提案になるのです。

各提案にはキーがあります。仕入先ならCNPJ、製品なら発行者側の製品コードです。同じフォルダーを2回アップロードしても何も重複しません。2回目の読み込みはすでに提案済みのものを認識し、新しい行を作りません。これがなければ、1年分のインボイスの初回取り込みで何千件もの重複が生じ、後からの整理はゼロから入力するより手間がかかります。

SPEDは読み込まず、在庫や資金の期首残高も計算しません。SPEDは別の経路です。レイアウトは毎年変わり、各ブロックの意味は会社の税制区分によって異なるため、中途半端に読むと正しい数字に見える誤った残高を生んでしまいます。スプレッドシートによる対応付けは、各登録画面にある既存のインポート経路で引き続き行います。

SPEDリーダーが取り込むのはマスタです。参加者は仕入先の提案に、品目は製品の提案になり、XMLと同じ重複キー（書類番号とコード）を使うため、同じ仕入先が2回入ることはありません。残高、税額計算、税額控除は意図的に対象外です。SPEDは暦年ごとにレイアウトが変わり、各ブロックの意味は税制区分によって異なるため、部分的な読み込みでは正しい数字に見える誤った期首残高が生まれてしまいます。照合は合うのに、数字は間違っているのです。マスタは名称、書類番号、説明なので、おかしなものが入ればすぐにわかります。ファイルがこのリーダーの知らないレイアウトであれば、無理に読もうとせず、受け取ったレイアウトを示して拒否します。

XMLそのものから、解釈なしで読み取ります。仕入先はインボイスの発行者（CNPJ、正式名称、州）から、製品は各明細（コード、説明、NCM、単位）から、支払額はインボイスの合計から取得します。XMLにはスキーマがあるため、読み取りは決定論的です。ここでAIが項目を推測することはなく、それは意図的です。誤ったCNPJを推測するくらいなら、インボイスを読まないほうがましだからです。