多くの現場で、ERPは真実の源泉であると同時に、再作業の起点でもあります。同じ納品書がSAPやTOTVSに登録され、その後TMSで集荷を発行するために再入力され、WMSのピッキングで再度照合され、さらに財務を締めるためにスプレッドシートへ書き出されます。受け渡しのたびに誤りが生じる余地があります。CFOPの取り違え、積荷明細書の重量の誤り、ECと在庫のあいだで消えてしまった受注などです。
Meta Dadosは、ERP（SAP、TOTVS、Sankhya、Omie）をオペレーション全体に接続し、在庫、財務、受注、NF-eをリアルタイムに同期させます。二重入力も、途中に挟まるスプレッドシートもありません。データは一箇所で生まれ、それを必要とするすべてのシステムへ、監査可能な形で流れていきます。
同じ納品書を二度打ちするコスト
二重入力は単なる遅さではありません。月次決算のときにWMSの在庫がERPと合わず表面化する不一致であり、TMS上の重量が手入力から来ていたために誤って請求される運賃であり、二つの部署が互いにすでに請求済みだと知らなかったために二重発行される納品書です。
ERPがTMS、WMS、販売チャネルと直接連携すれば、この見えないコストは消えます。
- 二重入力の終わり — 受注は一度だけ入力され、請求、出荷、財務を再入力なしで通過します。
- 単一の在庫 — WMSの引き落としが同じ瞬間にERPとECに反映され、裏付けのない販売を防ぎます。
- 自動消込 — NF-e、CT-e、請求書はアクセスキーで突き合わされ、手作業の照合ではありません。
- トレーサビリティ — 各レコードがどこから来ていつ入力されたかを保持します。監査は宝探しではなくなります。
ERPとその他システムのあいだで同期するデータ
統合はモジュール単位で構成されます。どれをプロジェクトに含めるかはお客様が決めます。多くの場合、もっとも痛みの大きいものから始めます。
- 在庫 — ERPとWMSのあいだの残高、引当、倉庫ロケーション、入出庫。入荷、出荷、棚卸がシステム間で一致します。
- 財務 — 買掛金と売掛金、消込、銀行照合、原価センター。TMSで実行された運賃が入力なしでERPの仕訳になります。
- 請求 / NF-e — 発行、SEFAZからの応答、取消、訂正状。ERPで発行された納品書が出荷と輸送を自動的に動かします。
- 受注 — EC（VTEX、Shopify）とB2Bの受注が、マスタ、価格、税務を正しく揃えた状態で検証済みとしてERPに入ります。ステータスは誰もスプレッドシートを更新することなくチャネルへ返されます。
各項目はシステム間でマッピング（対応付け）されます。SAPのCFOPがTMSの取引区分に対応し、TOTVSの製品コードがShopifyのSKUと一致します。このマッピングこそ統合が信頼できるものになる場所であり、まさにMeta Dadosが診断で行う作業です。
接続の方法：API、EDI、またはミドルウェア
唯一正しい方法というものはありません。あるのは、システムのペアごとに正しい方法です。私たちは好みではなく、お客様の環境の技術的な実態で選びます。
- API（REST/SOAP） — システムが最新のインターフェースを備えている場合の優先的な手段。SAP（BAPI、OData、RFC）、TOTVS（Protheus/DatasulのAPI）、Sankhya、Omie、VTEX、Shopifyは成熟したAPIを持っています。受信確認を伴うリアルタイム連携です。
- EDI — ファイルで運用する運送会社、顧客、大手小売との構造化されたフロー向け（XML形式のNF-e/CT-e、固定レイアウトの受注）。パートナーの標準がEDIであれば、それに合わせて統合します。
- ミドルウェア — システム間の統合レイヤーで、フォーマットを変換し、対応付けのルールを適用し、キューを制御し、失敗したものを再実行し、すべてを記録します。一つのシステムの停止が別のシステムを巻き込んで倒すのを防ぎます。
ミドルウェアは統合を堅牢にします。SEFAZが停止したりECが遅くなったりしても、メッセージはキューに残り再処理されます。何も失われず、オペレーション全体が止まることもありません。
統合するシステム
Meta Dadosは輸送・物流の専門家ですが、統合のエンジニアリングはあらゆるオペレーションに役立ちます。対応システムは以下のとおりです。
- ERP： SAP（ECCおよびS/4HANA）、TOTVS（Protheus、Datasul、RM）、Sankhya、Omie。
- TMS / WMS： RODOPARおよび市場の主要な輸送・倉庫管理システム。
- EC： VTEX、Shopify、各種マーケットプレイス。
- テレメトリー： SASCAR、Autotrac、Omnilink、Onixsat、Cobli、Geotab（輸送が同じフローに入る場合）。
これまでに50以上のシステムが私たちの統合を経ています。一般的でないシステムの場合は、それが持つインターフェース（データベース、ファイル、レガシーAPI）をマッピングし、同じように統合します。
プロジェクトの進め方：診断からリアルタイムまで
統合は既製品ではなく、お客様のオペレーションの上に築くエンジニアリングです。しかし道筋は見通せます。
- 診断（48時間、無料） — システム、データフロー、二重入力の所在をマッピングします。統合の設計図と、正直な工数見積もりをお渡しします。
- 対応付けのマッピング — どの項目をどのルールで同期し、まれなケース（返品、取消、不一致）をどう扱うかを定義します。
- 構築と検証 — テスト環境で統合し、実データで検証してから、はじめて本番に移します。
- 切替と監視 — 同期はアラート付きで稼働します。何か失敗すれば、顧客より先にお客様が気づきます。
単発の統合、たとえばECをERPに接続する場合などは、数週間と言えることが多いです。SAPやTOTVSの複数モジュールを含むプロジェクトは、オペレーションを止めないためにフェーズ分けします。診断こそが、この期間を当て推量から確約へと変えるものです。
よくある質問
SAPやTOTVSを統合するにはオペレーションを止める必要がありますか？
いいえ。統合は切替の前に、実データを用いて検証環境で構築・テストされます。本番に入る際、同期はフェーズ分けで、モジュールごとに一つずつ有効化されるため、移行中にオペレーションが止まることはありません。
ERPとTMSまたはECの統合にはどのくらい時間がかかりますか？
モジュール数と税務ルールの複雑さによります。VTEXやShopifyのECをERPに接続するような単発の統合は、数週間で完成することが多いです。SAPやTOTVSの複数モジュールを含むプロジェクトはフェーズ分けします。48時間の無料診断が、この見積もりをお客様のケースに合わせた具体的な期間へと変えます。
システム間で同期されるデータは何ですか？
在庫（残高、引当、入出庫）、財務（買掛金・売掛金、消込、照合）、請求とNF-e（発行、SEFAZからの応答、取消）、受注（マスタ・価格・税務を伴うECとB2B）です。どのモジュールを含めるかはお客様が選びます。多くの場合、もっとも再作業を生むものから始めます。
統合はリアルタイムですか、それともバッチですか？
システムが許す限り、連携はAPIによる受信確認を伴うリアルタイムです。パートナーがファイルでしか運用しない場合（運送会社や大手小売とのEDIによくあるケース）は、頻度の高いウィンドウでバッチを使います。ミドルウェアがキューを制御し失敗したものを再処理するため、どちらのシナリオでも何も失われません。
SAP S/4HANAやTOTVS Protheusでも動作しますか？
はい。SAPはECCおよびS/4HANA（BAPI、OData、RFC経由）で、TOTVSはProtheus、Datasul、RM（それぞれのAPI経由）で統合します。SankhyaやOmieにも対応します。ERPが最新のAPIを持たない古いバージョンの場合は、利用可能なインターフェース（データベース、ファイル、レガシーサービス）で統合します。
EDIとは何ですか、そしてAPIではなくEDIが必要になるのはどんなときですか？
EDIは、構造化・標準化された形式での文書交換です（XML形式のNF-eやCT-e、固定レイアウトの受注）。企業間、運送会社、大手小売のあいだで広く使われています。パートナーがこの標準を求める場合にEDIを使います。自社システム間の統合では、リアルタイムであるためAPIの方が優れていることが多いです。Meta Dadosは両方に対応し、各接続が求めるものに応じて選びます。