基幹システム連携の項目差異を揃える手順｜対応表の作り方と変換の置き場所の選び方

◆監修・編集責任者　小園 将隆　2026年10月7日

B2B EC-COLUMN

基幹システム連携で項目が合わないとき、まず差異を3種類に分ける

ECや会計など別のシステムから届いたデータを基幹システムに取り込むと、エラーで止まる行がある。
項目名は同じなのに金額や数量が合わず、そのたびに手で直している。
この状態は、差異を「名称」「形式」「意味・粒度」の3種類に分けると整理できます。
名称と形式の差は変換表で揃えられます。
一方、税込・税抜や端数処理、単位のような意味の差は、どちらを正とするかを業務として先に決める必要があります。
そのうえで項目対応表を作り、変換の置き場所を件数・頻度・変更の多さ・保守体制・費用で選びます。
置き場所に決まった正解はなく、自社の条件に当てはめて決めていきます。

名称の違い

取り込みでエラーが出た行と、エラーは出ないのに値が合わない行。
どちらも一件ずつ直したくなりますが、先に「何が違うのか」の種類を見分けると、同じ直し方で片づく行をまとめられます。
ここでは差異を、名称、形式、意味や粒度の3種類に分けます。
この分け方は制度や標準で定められた分類ではありません。
次に作る項目対応表の列にそのまま使える、実務上の整理です。

以下では、ECサイトで受けた注文を販売管理（基幹システム）へ取り込む連携を例にします。
ECがデータを送る側の連携元、販売管理が受け取る側の連携先です。
会計や勤怠、取引先のシステムとの連携でも、送る側と受け取る側を置き換えれば同じ考え方で読めます。

名称の違いは、同じ中身を別の名前で呼んでいる差です。
EC側の「注文番号」と販売管理側の「受注No」、「顧客」と「得意先」のような組み合わせがこれに当たります。
中身が同じなら、どの項目とどの項目を結ぶかを一度決めれば済み、変換はほとんど要りません。

注意したいのは逆の場合、つまり名前が同じなのに中身が違う項目です。
EC側の「備考」が購入者の自由記入欄で、販売管理側の「備考」が社内向けのメモ欄だとします。
名前が同じだからと結ぶと、購入者の書いた文章が社内メモに入ります。
その結果、伝票の印刷や出荷指示にそのまま出てしまうことがあります。
名称の差は、名前を見比べるだけで判断しないことが大切です。
実際に入っている値を見て中身が同じかを確かめれば、取り違えを防げます。

形式の違い（桁数・日付・文字種）

形式の違いは、中身は同じでも書き方が違う差です。
日付をYYYY/MM/DDのように区切るか、YYYYMMDDの8桁で続けるか。
電話番号にハイフンを入れるか。
カナを全角で持つか半角で持つか。
数量に小数を許すか、整数だけか。
取り込みエラーとして画面に現れやすいのは、たいていこの種類です。

形式の差で気をつけたいのは、エラーになる場合とならない場合があることです。
販売管理の品名欄に文字数の上限があり、EC側の商品名がそれより長いとします。
取り込みを止める仕様なら、担当者はすぐ気づきます。
しかし上限で切り詰めて登録する仕様なら、エラーは出ないまま、途中で切れた品名が伝票に載ります。
どちらの動きになるかはシステムごとに違うため、自社の取り込み仕様で確かめておくところです。
形式の差は規則を決めれば変換で揃えられます。
ただし、収まらない値を切るのか止めるのかは、変換の前に決めておく必要があります。

意味や粒度の違い（税込/税抜・単位・1対多）

項目名も書き方も揃っているのに値が合わない、という場面の多くはこの種類です。
EC側の「単価」が税込、販売管理側の「単価」が税抜なら、同じ「単価」でも数字は一致しません。
EC側は1個単位、販売管理側は箱単位で数量を持っている場合も、数字の意味が違います。

粒度の違いは、1件のデータが表す単位の違いです。
たとえば、1件の注文で届け先を複数指定できるEC側に対し、販売管理側が1受注につき1届け先しか持てない場合です。
この場合、1件の注文と複数の受注が対応する1対多の関係になります。
送料や値引きを、EC側は注文全体の項目として持ち、販売管理側は明細の1行として持つ、というずれもここに入ります。

この種類は、変換の式を書く前に、どちらの値を正とするか、どの単位で計算するかを決めないと解けません。
税額を例にとると、明細ごとに計算して足すか、伝票全体でまとめて計算するかで、合計が1円単位でずれることがあります。
システムの都合ではなく、経理や業務のルールとして決める話です。
変換で揃えられる差とは、扱いを分けておきます。

▼ 図の内容を文字で読む

• 名称の違い
  • 注文番号と受注No
  • 名前が同じでも実際の値で中身を確かめる
• 形式の違い
  • 日付の区切りや桁数
  • 収まらない値を切るのか止めるのかを先に決める
• 意味や粒度の違い
  • 税込と税抜、個と箱
  • 1対多は業務ルールを先に決める

項目対応表に書く列と、差異を洗い出す順序

対応表の列

項目対応表は、連携元と連携先の項目を1行ずつ結び、その間にある差と変換のしかたを書き込む表です。
表計算ソフトで作れます。
列は、前に見た3分類を書き込めるように、次のように並べます。

<ul><li>連携元の項目名</li><li>連携先の項目名</li><li>型（文字・数値・日付など）</li><li>桁数・文字数の上限</li><li>必須かどうか</li><li>値の例（連携元と連携先の両方）</li><li>差異の種類（名称・形式・意味や粒度）</li><li>変換ルール</li><li>決定者と決定日</li></ul>

このうち、あとで効いてくるのは「差異の種類」と「決定者と決定日」の列です。
差異の種類で絞り込めば、意味や粒度に当たる行だけを抜き出せます。
その行を、経理や業務の担当者と話し合う議題にできます。
決定者の列は、半年後に「なぜ税抜で取り込んでいるのか」と聞かれたとき、誰がいつ決めたかを表から答えるためのものです。
決めた本人が異動しても、理由をたどる手掛かりが表に残ります。

変換の置き場所や、制度にかかわる行の根拠資料などの列は、判断が進んだ段階で足していけば足ります。
最初から列を増やしすぎると、埋まらない欄が目立ち、表が使われなくなりがちです。
まずは差異を書き込める最小限の列から始めます。

必須項目と識別コードから始める

洗い出しは、全項目を上から順に埋めるより、次の順で進めるほうが手戻りが少なくなります。

<ol><li>必須項目と識別コード（取引先コード・品目コードなど）</li><li>形式の差（日付・桁数・文字種）</li><li>意味や粒度の差（税込・税抜、単位、1対多）</li></ol>

最初に必須項目と識別コードを扱うのは、ここが合わないと1件も取り込めないからです。
連携先が必須としている項目が連携元に無ければ、何で埋めるかを決めない限り先へ進めません。
識別コードは、取引先や品目を指し示す番号です。
ECの会員IDと販売管理の得意先コード、ECの商品コードと販売管理の品目コードが別々に採番されていれば、形式を整えるだけでは結び付きません。
どの会員がどの得意先に当たるか、という対応そのものを表にして持つ必要があります。
取引先や品目の数が多いほど、この準備には時間がかかります。

中核の項目から合わせる考え方は、企業間の受発注データの標準にも見られます。
中小企業共通EDI標準の仕様書は、注文メッセージの全135項目を定める一方で、業務アプリケーションに対応を求める最低限の項目を13項目としています¹。
取引先ごとにばらばらだったフォーマットを共通化し、注文・注文回答・出荷案内・請求のデータ形式を定義する設計です²。
全項目を一度に揃えるのではなく、取引が成り立つ中核を先に決め、そこから広げる作りと読めます。

ただし、これは企業間の受発注データのための標準で、社内の基幹システムと別システムの連携を対象にしたものではありません。
13項目という数も、業務アプリケーションに求められる最低要件です。
自社の連携で最低限必要な項目数を示すものではありません。
参考にできるのは数ではなく、中核から合わせていく順序の考え方です。

値の例で確かめる

項目名と型と桁数を書き写しただけでは、意味や粒度の差は見つかりません。
仕様書の上では「単価・数値・10桁」で一致していても、片方が税込で片方が税抜なら、表の上では差が見えないからです。
そこで、値の例の列には実際のデータを入れます。

実際に流れた注文を何件か選び、連携元での値と、連携先に取り込まれた値を並べて書きます。
選ぶときは、ふだんの注文だけに偏らないようにします。
送料や値引きがある注文、税率の違う商品が混ざった注文、キャンセルや返品が入った注文も含めます。
例外を含む注文ほど、1対多の関係や、項目の持ち方の違いが表に出やすいためです。
値を並べて初めて「単価が合わないのは税込と税抜の差だった」と分かれば、その行は形式ではなく意味の差として書き直せます。

▼ 図の内容を文字で読む

1. 必須項目と識別コード：合わないと1件も取り込めない
2. 形式の差：日付・桁数・文字種
3. 意味や粒度の差：税込・税抜、単位、1対多

変換で済む差と、業務ルールを決めないと解けない差

変換表で解けるもの

対応表に差異の種類が入ると、行は大きく2つに分かれます。
規則を決めれば機械的に置き換えられる行と、置き換える前に何かを決めなければならない行です。

機械的に置き換えられるのは、主に名称と形式の差です。
日付の区切りを取る、全角を半角に直す、ハイフンを除く、といった変換は、一度規則を決めればどの注文にも同じように当てはまります。
支払方法をEC側は「クレジット」という文字で、販売管理側は「1」という区分値で持っている場合も同じです。
文字と区分値の対応を表にしておけば置き換えられます。
識別コードも、どの会員がどの得意先に当たるかが決まれば、あとは対応表を引くだけの変換になります。

形式を揃える考え方は、企業間の標準にも表れています。
中小企業共通EDIの標準仕様は、国連CEFACTの共通辞書に準拠した形式で構成されています¹。
国連CEFACTは、貿易手続きや電子商取引の標準を扱う国連の機関です。
項目を共通の定義に寄せたうえで、形式を定める作りになっています。
社内の連携に置き換えるなら、項目の意味を先に揃えておけば、残る形式の差は変換で吸収できる、という順序の考え方として参考になります。

決定が先に要るもの

置き換える前に決めごとが要るのは、意味や粒度の差です。
代表的なものを挙げます。

<ul><li>税込と税抜：どちらの金額を正とし、もう一方をどこで計算するか</li><li>単位：個と箱のどちらで受け、換算に使う入数をどこで持つか</li><li>1対多：複数の届け先がある注文を、1受注にまとめるか、届け先ごとに分けるか</li><li>送料・値引き：注文全体の項目として持つか、明細の1行として持つか</li></ul>

これらは変換の式としては短く書けても、どの式を選ぶかで帳票や売上の数字が変わります。
連携を設定する担当者が自分の判断で選ぶと、その選択は変換の設定の中に埋もれます。
あとから見た人には、そこが決めごとだったことすら分かりません。
だからこそ、対応表の決定者の列には、その数字に責任を持つ人の名前を入れます。
税の扱いなら経理、出荷の単位なら物流の担当者、という具合です。

単位の換算は、一見すると変換で済みそうに見えます。
しかし箱の入数が商品ごとに違えば、換算の規則は1本ではなく商品ごとの値になります。
これは品目マスタ（商品ごとの基本情報をまとめた台帳）で持つべき情報です。
変換の規則に入数を直接書き込むと、新しい商品が増えるたびに変換の設定を直すことになります。
規則とマスタのどちらに持たせるかも、決定の対象です。

税の端数処理の扱い

決定が要る差のなかでも、税の端数処理は制度とかかわるため、社内の好みだけでは決められません。
国税庁がインボイス制度について公表しているQ&Aでは、適格請求書の消費税額等の端数処理は、一の適格請求書につき税率ごとに1回行うものとされています。
個々の商品ごとに端数処理をして合計する方法は認められない、とも示されています。

連携で問題になるのは、EC側が明細ごとに税額を計算して持ち、その値を足した合計が販売管理へ渡る場合です。
販売管理側で請求書を発行するなら、請求書に載る税額をどちらのシステムの計算で出しているかを確かめる必要があります。
EC側の明細ごとの税額をそのまま足していれば、制度の求める計算と合わない可能性があります。
その場合は、販売管理側で税率ごとにまとめて計算し直すのか、といった決定が要ります。

この扱いは、適格請求書を発行・受領する事業者の、請求書の記載事項についての話です。
社内の伝票や見積書の端数まで同じ方法に揃えなければならない、という意味ではありません。
また、制度の扱いは改訂されることがあります。
対応表のこの行を決めるときは国税庁の最新の資料で確かめ、決定者には経理の担当者を置くのが自然です。

▼ 図の内容を文字で読む

• 規則だけで置き換える
  • 日付の区切りを取る
  • 全角を半角に直す
• 対応が決まれば置き換える
  • 支払方法の文字と区分値の対応
  • 会員と得意先の対応
• 決定が先に要る
  • 税込と税抜の正をどちらにするか
  • 個と箱、複数の届け先、送料や値引きの持ち方

変換をどこに置くか：連携ツール・基幹側・中間処理・手作業の選び方

5つの条件

変換で揃えると決まった行は、次にどこで変換するかを決めます。
置き場所の候補は大きく4つです。

<ul><li>連携ツール：システム同士をつなぎ、項目の対応づけや値の変換を設定できるソフトやサービス</li><li>基幹側：基幹システムの取り込み設定やマスタで差を吸収する</li><li>中間処理：表計算のマクロや小さなプログラムで、連携元の出力を連携先の取り込み形式に整える</li><li>手作業：担当者が出力ファイルを開き、取り込み前に値を直す</li></ul>

置き場所の優劣を一般に示す資料はありません。
ここでは、自社の条件に当てはめて選ぶための考え方として、次の5つの条件を提案します。

<ul><li>件数：1回の連携で流れるデータの量</li><li>頻度：連携する間隔（毎日か、月に1回か）</li><li>変更の多さ：項目や変換ルールが変わる頻度</li><li>保守体制：変換の設定を直せる人が社内にいるか</li><li>費用：導入と維持にかかる費用</li></ul>

件数と頻度は、手で直す負担の大きさを決めます。
月に1回、数件の値を直すだけなら手作業でも回ります。
しかし毎日まとまった件数が流れるなら、同じ修正を毎日繰り返すことになります。
変更の多さと保守体制は、変換の置き場所を誰が直せるかの問題です。
変換ルールが年に何度も変わるのに、その設定を直せるのが外部の開発会社だけなら、変わるたびに依頼と待ち時間が発生します。
費用は、ツールの利用料や開発費だけでなく、設定を直すたびにかかる外部への依頼費も含めて見ると比べやすくなります。

方式ごとの向き不向き（提案）

4つの置き場所について、5つの条件に照らした向き不向きをまとめると次のようになります。
費用や機能は製品や契約によって違うため、金額や機能の有無ではなく、導入前に確かめる点として書いています。

表で判断が分かれやすいのは、基幹側と中間処理です。
基幹側は、すでにある取り込み設定やマスタで差を吸収できれば、追加の仕組みが要りません。
そのため最初に検討する価値があります。
一方で、基幹システムの設定は販売や会計の他の業務とつながっています。
連携のために変えた設定が、別の画面や帳票に影響しないかを確かめる必要があります。

中間処理は、表計算のマクロなど手元の道具で始めやすい反面、作った人がいなくなると誰も直せない状態になりやすい置き場所です。
中間処理を選ぶなら、対応表の変換ルールの列とマクロの中身が一致していることを保つ手間も含めて見積もっておきます。

異なるシステムの間の変換を、共通の仕組みに担わせる構想もあります。
中小企業庁が開発するとされた「データ連携基盤」は、業界やサプライチェーンごとに異なる電子受発注システムに接続し、入力データを自動変換する構想として2021年に報じられました³。
企業間の受発注が対象で、社内の基幹連携の置き場所を決める根拠にはなりません。
ただ、変換を個々の担当者の手元ではなく一箇所の仕組みに集める、という方向性の例として見ることができます。

条件別の選び方

実際の判断では、次の順で考えると迷いが減ります。
まず件数と頻度で、手作業が成り立つかを見ます。
成り立たなければ、基幹側の設定で足りるかを確かめます。
足りない分を、連携ツールか中間処理に回します。
基幹側を先に見るのは、すでに契約し使い慣れている仕組みで済むなら、新たに覚える場所を増やさずに済むからです。

置き場所は、連携全体で1つに決める必要はありません。
日付や文字種の変換は連携ツールで行い、会員IDと得意先コードの対応は基幹側の得意先マスタで持つ、というように、行ごとに置き場所が分かれることもあります。
その場合は、対応表に「変換の置き場所」の列を足し、どの行の変換がどこで行われているかを書いておきます。
変換が複数の場所に散らばったまま記録がないと、値が合わないときに、どこを直せばよいかを探すところから始めることになるからです。

同じ変換を2箇所に置かないことも大切です。
たとえば税抜への換算を連携ツールでも基幹側でも行っていると、二重に換算された金額が登録されます。
対応表で行ごとに置き場所を1つに決めておけば、こうした重複に気づきやすくなります。

▼ 図の内容を文字で読む

1. 件数と頻度を見る：手作業が成り立つかを確かめる
2. 基幹側の設定で足りるか：すでにある取り込み設定やマスタで吸収できるか
3. 連携ツールか中間処理：足りない分をここに回す

変換しきれない値が出たときの検知・戻し方・担当の決め方

検知する場所

対応表を整え、置き場所を決めても、変換しきれない値は出ます。
新しく登録された商品のコードが対応表にない、EC側で新しい支払方法が増えた、届け先の住所が文字数の上限を超えた、といった場合です。
このとき困るのは、値が合わないこと自体より、合わないことに誰も気づかないまま後工程へ流れることです。

そこで、どこで気づくかを先に決めておきます。
取り込みの結果画面に弾かれた行が表示されるのか、ログとしてファイルに残るのか、連携ツールから通知が届くのかは、システムや製品によって違います。
自社の連携でどこにエラーが現れるかを確かめます。
切り詰めのように、エラーにならない変換が起きていないかも見ておきます。
そのうえで、取り込みのたびに誰がその場所を見るかを決めます。

あわせて、変換できない値が来たときに止めるか、仮の値で通すかも決めます。
品目コードが見つからない注文を止めれば、誤った品目で出荷する心配はありません。
ただし、その注文の処理は直すまで進みません。
「未登録品」のような仮のコードで通せば処理は止まりませんが、仮のまま残った注文が月末の集計に紛れ込みます。
仮の値で通すなら、仮のコードが付いた注文の一覧を毎日確認する、といった後始末の手順とセットにします。

再処理の手順

エラーを見つけてから直し終えるまでの流れは、次のように決めておくと、担当者が替わっても同じ手順で進められます。

<ol><li>エラーになった行と、その原因（マスタの不足か、変換ルールの不足か）を特定する</li><li>マスタに登録するか、変換ルールを追加する</li><li>直した行だけを取り込み直す</li><li>対応表に、追加したルールや対応を書き足す</li></ol>

取り込み直すときに気をつけたいのは、二重の登録です。
エラーの出た注文だけを取り込み直すつもりが、同じファイルを丸ごと取り込み、登録済みの注文まで重複させてしまうことがあります。
注文番号のように1件ごとに重ならない番号で、登録済みかを確かめられるか。
自社の取り込み仕様で見ておきたい点です。

4番目の、対応表へ書き足す工程は省かれやすいところです。
しかし、ここで書き足さないと、同じ原因のエラーが次に出たとき、また原因を探すところから始めることになります。
エラーを直すたびに対応表へ書き足す流れにしておけば、エラーの原因と直し方が表の中に順にたまっていきます。

マスタ管理の担当

変換しきれない値の多くは、マスタの不足から生まれます。
マスタは、取引先や品目、税区分など、取引のたびに参照される基本情報の台帳です。
EC側で新しい商品を売り始めたのに、販売管理の品目マスタとの対応が未登録なら、その商品の注文は最初の1件目からエラーになります。

これを防ぐには、取引先・品目・税区分のそれぞれについて、誰がマスタを追加・変更し、いつまでに対応表を更新するかを決めておきます。
新商品なら、EC側に商品を登録する担当者が、販売開始の前に品目の対応を登録する順にしておきます。
そうすれば、最初の注文でのエラーを避けやすくなります。
取引先・品目・税区分で担当が分かれるなら、それぞれの担当者名を対応表に書いておくと、問い合わせ先に迷いません。

対応表を一人の手元のファイルにせず、関係する担当者が見られる場所に置くのは、このためです。
変換のルールとマスタの担当が表で共有されていれば、「なぜこの値に変わるのか」を設定した本人に聞きに行く手間が減ります。
口頭での引き継ぎに頼る部分も減ります。
表が担当者の代わりになるわけではありませんが、誰に聞けばよいかまでは表から分かるようになります。

▼ 図の内容を文字で読む

1. 行と原因の特定：マスタの不足か変換ルールの不足か
2. マスタ登録かルール追加：不足していたほうを直す
3. 直した行だけ取り込み直す：登録済みの注文を重複させない
4. 対応表へ書き足す：追加したルールや対応を残す

項目追加や制度変更があったときの変換ルールの保守

制度変更の確認

連携は、動き始めたあとも変わり続けます。
連携先のシステムに項目が増える、税の扱いが変わる、取引先が増える。
そのたびに対応表と変換の設定がずれていくと、最初に整えた表はやがて実態と合わなくなります。

制度にかかわる行には、根拠となる資料の名前と、その資料を確かめた時期を書く列を足しておきます。
税の端数処理の行なら、国税庁のQ&Aを根拠として挙げ、確かめた年月を記録する形です。
制度の扱いが変わったと知ったときは、所管する機関の一次資料で適用される時期を確かめます。
そのうえで、該当する行の変換ルールと決定者、確認した時期を更新します。
確認した時期が古い行を定期的に見直せば、制度の変更に気づかず古い計算のまま連携している状態を見つけやすくなります。

ここで大切なのは、変更を予測して先回りすることではありません。
変わったときに、どの行を直せばよいかがすぐに分かることです。
制度に連動する行に根拠資料が書かれていれば、変更の知らせを受けた日に、確かめるべき行を表から絞り込めます。

項目追加の手順

連携先や連携元が項目を追加したときは、本番に反映する前に対応表を更新する順にします。
反映したあとで表を直そうとすると、表の更新が後回しになり、そのまま忘れられることがあるためです。

<ol><li>項目追加の知らせを受けたら、対応表に新しい行を足す</li><li>差異の種類（名称・形式・意味や粒度）を判定する</li><li>意味や粒度の差なら、決定者を決めて業務ルールを決める</li><li>変換ルールと置き場所を決め、テスト用のデータで取り込みを確かめる</li><li>本番に反映し、対応表の版を上げる</li></ol>

2番目の判定で意味や粒度の差と分かった場合は、3番目の決定に時間がかかることがあります。
連携先の追加日が先に決まっているなら、決定が間に合わない間はその項目を連携しない、といった暫定の扱いを選べるかも検討します。
追加された項目が必須でなければ、連携しなくても取り込みは止まらないためです。

対応表の版管理

対応表は、変更のたびに版数を上げ、変更した時期、変更内容、変更した人を記録します。
古い版も消さずに残しておきます。

古い版が要るのは、過去のデータを見返すときです。
前の年の請求額を確かめようとしたとき、当時の変換ルールがいまと違えば、いまの表だけではなぜその金額になったのかを説明できません。
版ごとの表が残っていれば、その時期にどのルールで変換していたかをたどれます。

版管理といっても、特別な仕組みは要りません。
表計算のファイル名に版数を付けて保存し、表の最初のシートに変更履歴を書いておくだけでも、どの時期にどのルールだったかは分かります。
大切なのは、変換の設定を変えたときに、必ず表も同時に変える、という順序を守ることです。

▼ 図の内容を文字で読む

1. 対応表に新しい行を足す：項目追加の知らせを受けたら
2. 差異の種類を判定する：名称・形式・意味や粒度
3. 決定者を決めて業務ルールを決める：意味や粒度の差の場合
4. 変換ルールと置き場所を決めて確かめる：テスト用のデータで取り込む
5. 本番に反映し版を上げる：対応表も同時に更新する

対応表のどの行が変換で済み、どの行に業務ルールの決定が要るかは、自社の連携元と連携先の実際の値を並べてみないと判断しにくいためです。

手元の項目一覧や取り込みエラーの例をもとに、差異の種類の切り分けと、先に決める必要がある行を一緒に確かめられます。無料相談で要件を整理する

要点の整理

差異の分け方	名称・形式は変換で揃え、意味や粒度は業務ルールを先に決める
洗い出しの順	必須項目と識別コード → 形式 → 意味や粒度
対応表で効く列	値の例・差異の種類・決定者と決定日
置き場所の条件	件数・頻度・変更の多さ・保守体制・費用
置き場所の記録	行ごとに1箇所に決め、対応表に書く
エラーの扱い	止めるか仮の値で通すかを決め、直したら対応表へ書き足す
保守	制度に連動する行に根拠資料を書き、変更のたびに版を上げて古い版も残す

変換の置き場所は件数や保守体制など自社の条件で変わり、基幹側の設定でどこまで吸収できるかも製品ごとに違うためです。 いまの連携の件数・頻度・設定を直せる人を整理し、どの行の変換をどこに置くかの候補と、運用で決めておく担当を確かめられます。

よくある質問

項目名は同じなのに値が合わないとき、最初に何を見ればよいですか。

同じ注文について、連携元の値と連携先に取り込まれた値を並べて見ます。
差が一定の割合なら税込と税抜、一定の倍数なら単位の違いが疑われます。
ただ、差の大きさだけで決めつけず、実際の明細や商品の条件と照らし合わせて確かめます。
意味の差と分かれば、変換の式より先に、どちらの値を正とするかを決める行として対応表に書きます。

項目対応表は表計算で作ってよいですか。何列あれば足りますか。

表計算で作れます。
最初は、連携元と連携先の項目名、型、桁数、必須かどうか、値の例、差異の種類、変換ルール、決定者と決定日の列があれば、差異を書き込んで判断を残せます。
変換の置き場所や、制度にかかわる行の根拠資料は、必要になった段階で列を足せば足ります。
列の数より、関係する担当者が同じ表を見られる場所に置くことのほうが大切です。

税込・税抜が連携元と連携先で違う場合、どちらに合わせればよいですか。

一律には決まらず、売上や請求の金額をどちらのシステムで確定させるかで決めます。
請求書を発行する側のシステムで計算する、というのが一つの考え方です。
適格請求書を発行する場合は、税の端数処理が一の請求書につき税率ごとに1回とされている点も踏まえ、どこで税額を計算するかを経理の担当者が決めます。
決めた内容は、対応表の決定者と決定日の列に残します。

変換ルールを文書化するのは誰が望ましいですか。

変換ルールの中身を決めるのは、その数字に責任を持つ業務の担当者です。
税なら経理、単位なら物流や購買の担当者が当たります。
一方、対応表に書き込み、変換の設定と表がずれないように保つのは、連携の設定を担う人が向いています。
決める人と書く人を分けたうえで、表全体の更新に責任を持つ人を1人決めておくと、更新漏れに気づきやすくなります。

連携先が項目追加をしたとき、どの時点で対応表を更新しますか。

追加の知らせを受けた時点で行を足し、本番に反映する前に変換ルールと置き場所を決めて表を更新します。
反映後に表を直す順にすると、更新が後回しになりやすいためです。
意味や粒度の差を含む項目で決定が間に合わない場合、その項目が必須でなければ、いったん連携しないという暫定の扱いも選べます。

取引先コードが両システムで違う場合、対応づけはどこで持てばよいですか。

どの取引先がどのコードに当たるかの対応は、1箇所で持つのが基本です。
基幹システムの取引先マスタに外部のコードを登録できる欄があればそこで持ち、無ければ連携ツールや中間処理の対応表で持ちます。
マスタに外部コードの欄があるかは製品ごとに違うため、自社の基幹システムで確かめます。
同じ対応を2箇所で持つと片方だけ更新されてずれる原因になるため、どこで持っているかを対応表に書いておきます。

1. 1　出典：中小企業庁（ミラサポplus）「企業間のデータ連携で、受発注の業務コストを削減する！（中小企業共通EDI標準仕様書の解説）」（2020年）
2. 2　出典：つなぐITコンソーシアム（ITコーディネータ協会 共通EDI標準部会）「中小企業共通EDIとは」（2016年）
3. 3　出典：日刊工業新聞社（ニュースイッチ）「中小企業庁が中小企業の電子受発注実現へ開発する「データ連携基盤」の全容」（2021年）