サイト間メッセージ処理

サイト間オーダー セットは基本的に次のものから構成されます。

開始点は、受注オーダー、購買オーダー、または社内間オーダーです。これらのオーダーは、たとえば計画ツールによって作成できます。開始点が受注オーダーまたは購買オーダーであり、[IFS コネクティビティ] が使用されている場合、2 つのサイト間で異なるメッセージが送信されます。このドキュメントでは、開始点が以下の場合のサイト間取引状況で使用できるメッセージについて説明します。

2 つのサイト間の数量を再計算する際に、システムでは、 仕入先別購買品目ページに入力された変換係数、および適切な場合には 顧客別商品ページに入力された変換係数が使用されることに注意してください。つまり、2 つのサイト間で計量単位が実際に異なる場合でも、変換係数が 1 の場合、システムは警告も変換も行いません。

受注オーダー

この件に関する詳しい情報については、次のドキュメントを読むことをお勧めします。引当管理について、[サプライチェーン供給] について、[EDI メッセージ] について。

外部受注オーダーを社内で供給する場合、資材フローに応じて 2 つの異なるシナリオがあります。

積替出荷

[積替出荷] による社内オーダーの場合、次のメッセージが使用されます。

外部受注オーダーをリリースすると、社内購買オーダーが自動的に作成されます。オーダー メッセージは自動的に作成され、送信されます。このメッセージは供給サイトによって受信されます。承認を自動的に行うか、手動で処理するかを決定できます。承認されると、供給サイトに社内顧客オーダーが作成されます。

供給サイトでは、社内顧客オーダーは他の通常の受注オーダーと同様に処理されます。

需要サイトが購買オーダーを変更する必要がある場合、ORDCHG メッセージが供給サイトに送信され、供給サイトでは変更が承認または拒否されます。

供給サイトは、ORDRSP メッセージを使用してオーダーを確認できます。

必要に応じて、DESADV メッセージ (梱包検証と組み合わせて) を使用して、詳細な納品書を電子的に需要サイトに送信できます。

需要サイトでは、品目の到着を登録し、払出、納入、請求を行って通常どおり外部受注オーダーを処理します。システムは自動的に資材を元の受注オーダーに紐付けるため、引当は必要ありません。

相互作用するサイトが同じ金融会社に属している場合、社内請求書は作成されません。サイトが異なる会社に属している場合、供給サイトは請求書を作成し、それを INVOIC メッセージとともに需要サイトに電子的に送信できます。

直納

直納による社内オーダーの場合、他のメッセージも関係します。

需要サイトが外部受注オーダーをリリースすると、社内購買オーダーが自動的に作成されます。オーダー メッセージは自動的に作成され、送信されます。このメッセージは供給サイトによって受信されます。承認は、ユーザーの決定に応じて自動的に行われるように設定することも、手動で処理されるように設定することもできます。メッセージを承認すると、社内顧客オーダーが作成されます。

供給サイトでは、社内顧客オーダーは他の通常の受注オーダーと同様に処理されますが、納入先住所は需要サイトの住所ではなく、最終顧客の住所になります。

需要サイトが購買オーダーを変更する必要がある場合、ORDCHG メッセージが供給サイトに送信され、供給サイトでは変更が承認または拒否されます。

供給サイトは、ORDRSP メッセージを使用してオーダーを確認できます。

必要に応じて、供給サイトは DIRDEL メッセージを使用して、需要サイトに直納通知を送信できます。

需要サイトでこのメッセージを承認すると、社内購買オーダーが [完了] ステータスに変更され、これにより外部受注オーダーに商品が配送されたことが通知され、外部受注オーダーのステータスが自動的に [納入済] に変更されます。その時点で、需要サイトは外部顧客に請求書を発行できます。

相互作用するサイトが同じ金融会社に属している場合、社内請求書は作成されません。サイトが異なる会社に属している場合、供給サイトは請求書を作成し、INVOIC メッセージとともに需要サイトに電子的に送信できます。

購買オーダー

配送センターが中央在庫から補充する場合、次の 2 つのシナリオが考えられます。

非連続

このフローでは次のメッセージが使用されます。

配送センターが商品の需要に気付くと、発注点などの計画ツールの使用または手動で、中央在庫に対して購買要求が作成されます。この購買要求は、社内仕入先として機能する中央在庫への購買オーダーに変換されます。購買オーダーは、ORDERS メッセージとともに手動で他のサイトに送信されます。

オーダー メッセージは供給サイトで受信されます。承認は、ユーザーの決定に応じて自動的に行われるように設定することも、手動で処理されるように設定することもできます。承認すると、供給サイトに社内顧客オーダーが作成されます。

需要サイトが購買オーダーを変更する必要がある場合、ORDCHG メッセージが供給サイトに送信され、供給サイトは変更を承認または拒否します。

供給サイトは、ORDRSP メッセージを使用してオーダーを確認できます。

供給サイトでは、社内顧客オーダーは他の通常の受注オーダーと同様に処理されます。

必要に応じて、DESADV メッセージ (梱包検証と組み合わせて) を使用して、詳細な納品書を電子的に需要サイトに送信できます。需要サイトでは通常通り品目の到着を登録し、在庫を補充します。

相互作用するサイトが同じ金融会社に属している場合、社内請求書は作成されません。サイトが異なる会社に属している場合、供給サイトは請求書を作成し、INVOIC メッセージとともに需要サイトに電子的に送信できます。

繰り返し

反復的なシナリオでは、納入計画はサイトによって送受信されます。このシナリオは、上で述べたシナリオと非常に似ています。

使用されるメッセージは次のとおりです。

これはフローの図です:

配送センターが商品の需要に気付くと、MRP などの計画ツールを使用するか手動で、中央在庫に対する納入計画または仕入先納品計画が作成されます。スケジュール オーダーは、DELSCH メッセージを使用して手動または自動で他のサイトに送信されます。

DELSCH メッセージは供給サイトで受信されます。承認は、ユーザーの決定に応じて自動的に行われるように設定することも、手動で処理されるように設定することもできます。承認されると、供給サイトに顧客納品計画が作成されます。

供給サイトでは、顧客納品計画が通常通り処理されます。

必要に応じて、DESADV メッセージ (梱包検証と組み合わせて) を使用して、詳細な納品書を電子的に需要サイトに送信できます。需要サイトでは通常通り品目の到着を登録し、在庫を補充します。

相互作用するサイトが同じ金融会社に属している場合、社内請求書は作成されません。サイトが異なる会社に属している場合、供給サイトは請求書を作成し、INVOIC メッセージとともに需要サイトに電子的に送信できます。

注釈:24R2 のタイム ゾーンの改善により、受信した受注オーダーと受信した変更要求ページがサイトに注釈付けされます。ユーザーがサイト間フローを処理すると、作成された受信受注オーダーで、需要サイトのタイムゾーンでの希望納入日が新しいバッジとともに表示されます。作成日は、それぞれのバッジとともに供給サイトのタイムゾーンで表示され、データベース レベルでは需要サイトの時間で保存されます。受入日もバッジとともに供給サイトのタイムゾーンで表示されますが、サーバーのタイムゾーンで保存されます。明細レベルの日付は、需要サイトのタイムゾーンで表示および保存されます。これは、受信した変更要求についても同様です。受信した受注オーダーまたは受信した変更要求が承認され、社内顧客オーダーに、供給サイトのタイムゾーンに応じたすべての日付/時刻属性がそれぞれのバッジとともに表示されるのを確認できます。タイムゾーン対応のリクエストを使用して、サードパーティ ツールから受信受注オーダーまたは受信変更リクエストを作成する場合、「InternalCustSite」は必須で有効である必要があり、明細レベルの希望納入日はタイムスタンプ UTC 形式である必要があります。