物流モジュール

出荷のグルーピングと積込を最適化します。複雑なルート最適化については、専門のTMSパートナーと連携します。

はい、自動通知と注文ごとの追跡ビューにより確認できます。

WMSは倉庫内を管理し、Logisticsは倉庫から出ていくものを管理します。両者が揃うことで、生産から顧客までのループが完結します。

運送会社側が何を受け取れるかで決まります。ここを軽く見積もられることが多い部分です。大手のフォワーダーであれば所定のフォーマットのデータやAPI連携を受け付け、追跡番号を返してきます。一方、地場の運送会社はメールで送ったPDFの積込明細で運用していて、こちらに返ってくるデータは何もない、というのが普通です。接続は運送会社ごとに個別に要件定義します。相手が今の時点で受け取れない形式は、それ自体が一件のインターフェース開発案件になるとお考えください。

入数、パレットの積み付けパターン、総重量、そして実際に手配しているトラックやコンテナの車種・サイズです。受注のグルーピングは結局これらの数字の計算なので、品目マスタのパレット入数が間違っていれば、車両に載らない積み付けがそのまま計画として出てきます。あわせて配送カレンダーと得意先の入荷受付時間も必要です。これがないと、先方の荷受け場が受け付けない日付をシステムが約束してしまいます。

トラック横でパレットまたは荷姿単位に1スキャンが増えるので、一貫パレットの積込なら数秒の話です。時間が効いてくるのは混載とバラ積みで、カートン1個ごとに確認作業が発生します。これで潰せるのは「パレットを別のトラックに積んでしまう」類のミスであって、梱包工程で作り間違えた、あるいはラベルを貼り間違えたパレットは対象外です。そちらはもっと前工程で止めるべき検査です。プロセスを決める前に、一番手のかかる積込を、実際に作業する積込担当者と一緒にストップウォッチで測ってください。

部分的には使えます。自社工場内で起きたことは全部残ります。出荷伝票の作成、積込完了、構内ゲートの通過、それに配送書類一式です。つまり、その出荷をいつ組んで、いつ積んで、いつ門を出たかというタイムスタンプ付きの記録にはなりますが、走行中の現在地ではありません。ゲートを出た後は運送会社がステータスを返してくるかどうかに依存するので、追跡画面のカバー範囲は、どの運送会社と連携したかで決まります。

通常、受注と確定した納期回答日はERP側が持ち、Logisticsは手元の在庫、生産計画、輸送リードタイムでその日付が本当に守れるかを判断します。両者が食い違ったとき、どちらを顧客に伝えるかは誰かが決めなければなりません。これは業務ルールの問題で、たいていは受注・出荷業務のオーナー部門が引き取ることになります。

すでに保有しているデータから出荷まわりの帳票は作成します。納品書、パッキングリスト、出荷ラベルです。インボイスは価格情報を持つシステム、通常はERPから出ます。HSコード、原産地、インコタームズを判断するものではありませんし、税関に申告を行うものでもありません。したがって、自社通関をすでに行っている場合を除き、通関業者は引き続き必要です。

積込リストは実際に車両に積んだ現物に対して消し込むので、出荷は積んだ数量で締め、残りは後日の出荷分として残ります。納品書は積込実績から作成されるため、書類とパレットの数が合わないという事態を防げます。不足分をバックオーダーとして残すのか、配車ごと組み直すのかは、営業側と決めておくルール次第です。