経費精算システムの金蝶雲星空連携：伝票推送フィールドとよくあるエラー

連携の難しさは決してインターフェースの呼び出し方ではなく、補助核算ディメンションをどう伝え、会計期間の状態をどう検証するか——この2か所がエラーの主な発生源である。インターフェース自体には標準ドキュメントがあり、それに従って書けばよい。本当に時間がかかるのは、経費管理側の部門・プロジェクト・従業員コードを、金蝶側の基礎データと突き合わせることだ。

証憑連携の必須フィールド

補助核算が最も詰まりやすい一環だ

金蝶の科目は複数の核算维度を紐付け可能で、しかも科目ごとに求められるディメンションが異なる。管理費は部門だけでよいかもしれないが、研究開発支出はプロジェクトも必要で、その他未払金は従業員が必要である。

経費管理側が各科目にどの次元が必要かを把握していない場合、すべて送信するかすべて送信しないかのどちらかしかできません。前者は科目が受け付けない次元を送信する可能性があり、後者は次元不足で拒否されます。

正しい方法は経費管理側の科目マスタデータに required_dims フィールドを維持する、証憑生成時に科目要件に従って充填及び検証し、不足があれば草稿段階で報告する。

コードが合わない場合はどうするか

経費管理システムの部門コードは、金蝶の基礎資料と一致しないことがあり、特に経費管理がOAやHRの組織構造を使用している場合に顕著です。

この時必要になるのが1枚のコード変換対照表：経費管理側コード → 金蝶側コード。この表は実施段階で構築・維持する必要があり、両側のコードが自然に一致することを期待してはいけません。

調査段階で必ず確認すべき問題は：ディメンション値のコードが両側で一致しているか、一致しない場合に変換表が必要か。

よくある5種類のエラー

この5種類のうち、前の4種類はすべてプッシュされる前に阻止される。Kingdeeがエラーコードを返してから調査すると、財務が見るのは技術情報であり、どの伝票に問題があるのかも、どう修正すべきかも分からない。

冪等性：同一の伝票から2枚の証憑を生成できない

インターフェースのタイムアウト、ネットワークの揺らぎ、手動再試行により、同一の経費精算伝票が複数回送信される可能性がある。データベースレベルで一意インデックスを構築しなければならない、「精算書番号＋業務タイプ」を一意キーとして使用し、アプリケーション層の判断だけに頼りません——並行処理の場合、アプリケーション層の判断は無効になります。

失敗再試行の状態機械

失敗原因は完全に記録し、財務が読める形で提示しなければならず、単にエラーコードを保存するだけではならない。

無効化は赤伝票で、削除しない

経費精算伝票が無効または返戻された場合、赤字数値の証憑を生成して戻し、元の証憑は保持する。理由は二点：会計アーカイブの完全性要件、および総勘定元帳システムは通常記帳済み証憑の削除を許可しないため。