基幹システムへのCSV取込でよくあるエラーと対処法(文字コード・列順・0落ち)

基幹システムへのCSV取込でエラーが出ると、原因を探すのに製品マニュアルとにらめっこすることになりがちです。各ベンダーのFAQは自社製品限定の説明が中心で、「うちのシステムでは何が起きているのか」を製品名から探し当てるのは意外と手間がかかります。

この記事では、販売管理・仕入管理などの基幹システム全般で共通して起きやすいCSV取込エラーを、エラーメッセージや症状から原因を逆引きできる形で整理しました。特に見落とされがちな「0落ち」(先頭のゼロが消える現象)は、他の記事ではあまり詳しく扱われないため、この記事で重点的に取り上げます。

症状1: 「文字化けする」「?や□に置き換わる」→ 文字コードの不一致

原因: 国内の基幹システムの多くはShift_JIS(CP932)を前提にしていますが、ExcelやWebサービスで作ったCSVはUTF-8であることが増えています。この不一致が文字化けの主因です。

対処: CSVを保存し直す際、Excelなら「CSV(カンマ区切り)」形式(多くの環境でShift_JIS相当)を選ぶ。UTF-8前提のツールで作った場合は、テキストエディタで文字コードをShift_JISに変換してから取り込む。機種依存文字(①、㈱など)が品名・取引先名に含まれている場合は、変換時にエラーや欠落が起きやすいため事前に置き換えておく。丸数字やローマ数字がなぜ文字化けするのか、文字コードを揃えるだけでは解決しない理由は受注データのCSVで①②③やローマ数字が文字化けする理由にまとめています。

ただし、Shift_JISが常に正解とは限りません。クラウド型の販売管理・ERPには取込用ファイルをUTF-8で保存するよう案内しているものがあり、キャムマックスやfreee販売は公式にCSV UTF-8での保存を案内しています。複数のシステムを併用しているなら、「自社の標準はShift_JIS」と決め打ちせず、取込先ごとに文字コードを指定して出力できる状態にしておくほうが安全です。

症状2: 「列がずれて取り込まれる」「違う項目に値が入る」→ 列順・列数の不一致

原因: 基幹システムごとに、CSVに期待する列の並び順・列数・ヘッダー行の有無が異なります。取引先が複数の基幹システムを使い分けている場合、1つの固定フォーマットでは対応しきれません。

対処: 取込先の仕様書(列順・列数・ヘッダー有無)を手元に置き、出力側もそれに合わせて列を並び替える。取引先(取込先システム)ごとに列の並びが違うなら、システムごとに出力テンプレートを分けて管理する。

受注の入り口自体が複数ある場合(BtoBプラットフォーム受発注などのEDIとFAX・電話の注文が混在する場合)も考え方は同じです。基幹に渡す直前のCSVの形をどちらも同じ列名・列順に揃えておけば、入り口が増えてもこのチェックリストがそのまま使えます。詳しくはBtoBプラットフォーム受発注の注文データを自社の基幹システムに取り込むにまとめています。同じ考え方はBカートやCO-NECTのようなBtoB ECプラットフォームでも当てはまり、カスタムCSV機能で基幹システム側の列構成に合わせる具体的な手順をBカートの受注データを販売管理システムに取り込むとCO-NECTの受注データを基幹システムに取り込むで整理しています。列がずれる原因はシステム間の仕様差だけとは限りません。商品名に「オイル(1,000ml)」のようなカンマや改行が含まれていると、クォーティング(ダブルクォートで囲む処理)が崩れて同じように列がずれることがあります。基礎は受注データのCSVで列がずれるにまとめています。

症状3: 「エラーは出ないのに商品コードが変わっている」→ 0落ち(先頭ゼロの消失)

これが最も見落とされやすく、かつ発覚が遅れやすいエラーです。

原因: 商品コードや取引先コードが「0012345」のように先頭にゼロを含む場合、CSVをExcelで開いて保存し直すと、Excelがその列を「数値」と自動判定し、先頭のゼロを削って「12345」に変換してしまうことがあります。CSV自体はテキストファイルですが、Excelで一度開いて上書き保存すると、この変換が起きます。

• 症状が厄介な理由: 取込エラーにはならないことが多いのが特徴です。「12345」という別のコードとして解釈できてしまう場合、エラーメッセージが出ないまま、意図と違う商品・取引先として登録されてしまいます。誤出荷や誤請求につながって初めて気づく、というケースも起こり得ます
• 起きやすい場面: FAXの手書き注文書から品番・取引先コードを転記し、いったんExcelで整形してからCSVとして保存する、という一般的な運用フローの中で発生しやすい

対処:

• Excelで作業する場合、コード列のセル書式をあらかじめ「文字列」に設定してから入力・貼り付けする(数値として解釈されなくなる)
• 既に数値化してしまったコード列は、="0012345"のような数式やTEXT関数で文字列として復元してから保存し直す
• 取込前に、コードの桁数が本来の桁数と一致しているかを検算する(例: 本来7桁のコードが5桁になっていたら0落ちを疑う)
• Excelを経由せず、テキストエディタやCSV専用ツールで編集する運用に切り替えるのも有効な回避策

JANコードやバーコードのような長い数値も同じくExcelでの自動変換に注意が必要ですが、症状は0落ちとは異なります。「1.23E+12」のような指数表記に変わってしまうと、桁が丸められて元の数値には戻せません。0落ちとの違いと予防策は受注データのJANコード・バーコードがExcelで「1.23E+12」に変わってしまうで整理しています。

症状4: 「日付として認識されない」「日付が意図と違う」→ 日付形式の不一致

原因: 西暦/和暦、区切り文字(/か-か)、年の桁数(4桁か2桁か)、ゼロ埋めの有無など、日付の表記は基幹システムごとに期待する形式が異なります。

対処: 取込先が期待する日付形式をマニュアルで確認し、CSV側をその形式に統一する。手入力段階で担当者ごとに表記が揺れやすい(「7/23」「R8.7.23」など)ため、CSV化する前にまとめて確認・統一する工程を挟むとエラーを減らせます。揺れるのは日付だけではありません。単位つきの数量(「10ケース」)、全角数字、金額のカンマも同じ性質の問題で、CSVを作る側で先に決めておける正規化のルールはFAX注文書をCSVにする前に整えたい「表記ゆれ」にまとめています。税率の区分も、品目ごとに扱いが分かれる点で同じ性質の管理項目です。軽減税率8%と10%が混在する食品卸のケースで税区分列をどう持たせるかは軽減税率8%と10%が混在する受注データに整理しています。取込エラーにはならないのに金額だけ1円合わない場合は、日付や税区分とは別の原因(CSV側と基幹側で端数処理の方式が食い違っている)が疑われます。受注データのCSVで金額が1円合わないに、四捨五入・切り捨て・切り上げのどこで食い違いやすいかをまとめています。

取込前チェックリスト

エラーが出ない0落ちのようなケースもあるため、取込後に件数・桁数をざっと目視確認するひと手間が、結果的にいちばん確実な予防策になります。注文書の枚数・CSVの行数・取込結果の件数を突き合わせる具体的な検算手順はCSVを取り込んだのに件数が合わないに、逆に「念のためもう一度」で同じCSVを二重に取り込んでしまった場合の戻し方と防ぎ方は受注CSVを二重に取り込んでしまった時の戻し方と、そもそも重複させない取込ルールにまとめています。

なお、お使いの販売管理ソフトが決まっている場合は、ソフト別の取込仕様に踏み込んだ記事もあわせてご覧ください。パッケージ系は商奉行(奉行シリーズ)・PCA商魂・販売大臣(応研)・アラジンオフィス(アイル)・大塚商会SMILE(販売)、クラウド系は楽楽販売(ラクス)・キャムマックス・マネーフォワード クラウド(請求書・債権管理)・freee販売について、それぞれの必須項目・受入条件と、マスター(取引先・商品)を先に伝票を後にという取込の順番を具体的に整理しています。パッケージ・クラウド型の販売管理システムを導入せず、kintoneで受注管理を自前で組んでいる場合も、更新キー・文字コード・数値フィールドの先頭ゼロ落ちなど、同じチェック項目の多くがそのまま当てはまります。

基幹システムへの取込を乗り越えても、業務はそこで終わりません。出荷段階では配送業者の送り状発行システム向けに別のCSVを用意する工程が控えており、詰まりやすいポイントは送り状(出荷伝票)CSVを作るときに詰まりやすいところに、取引先マスタ側で管理しておきたいインボイス登録番号の持たせ方は取引先のインボイス登録番号、受注データ側でどう持てばいい?にまとめています。

手前味噌の紹介

この記事を書いているのは、注文書特化サービス注文書係(ちゅうもんしょがかり)の運営者です。品番・取引先コードは文字列として扱われるため、Excel経由での0落ちのような意図しない変換は起きません。CSVの文字コード(Shift_JIS/UTF-8)・列順は取引先や基幹システムごとに一度登録すれば、次回から自動で同じ形式で出力されます。

無料トライアル(30枚または14日間、クレジットカード登録不要)で、実際の注文書とお使いの基幹システムとの相性を確かめてみてください。