mtl_supply テーブルの役割は、元のトレーニング中に整理して投稿しました。
1. 購入要求が作成され、承認されると、mtl_supply が変更されます。 、MTL_SUPPLY は空です
b. 承認後、mtl_supply、supply_type_code=REQ にデータが生成されます
c 購買依頼が承認されると、購買依頼ヘッダーと購買依頼明細が MS.REQ_HEADER_ID、MS.REQ_LINE_ID に保存されます。今回は MS.SUPPLY_TYPE_CODE= REQ
2. PO が作成され承認されると、mtl_supply
a が変更されます。承認されていない場合、MTL_SUPPLY は空になります。 mtl_supply の元の Supply_type_code=REQ は、supply_type_code=PO
c に変更されます。一般的に、購買要求が発注書として自動的に作成されると、承認された発注書がキャンセルされると、その Supply_type_code=REQ は Supply_type_code=PO
d に変更されます。 、MTL_SUPPLY の Supply_type_code=PO が、supply_type_code=REQ
e に変更されました。--購買要求によって発注書を自動的に開くプログラムを呼び出すとき、承認されなかった場合、MS.PO_HEADER_ID、MS.PO_LINE_ID、
--MS.PO_RELEASE_ID承認済みの場合、MS.PO_LINE_LOCATION_ID、MS.PO_DISTRIBUTION_ID は空です
--MS.REQ_HEADER_ID、MS.SUPPLY_TYPE_CODE=PO は、数量を変更するか、PO 注文に新しい注文明細を追加します。
-- ただし承認されていません。元の承認された発注書明細行のデータは変更されませんが、新しく追加された明細行はテーブルに入力されません
-- 承認された発注書がキャンセルされると、MTL_SUPPLY の Supply_type_code=PO が Supply_type_code=REQ に変更されます。 、
--MS.REQ_HEADER_ID、MS.REQ_LINE_ID は、元の購入要求のヘッダーと行の値に同時に入力されます。MS.PO_HEADER_ID、MS.PO_LINE_ID、
--MS.PO_RELEASE_ID、MS.PO_LINE_LOCATION_ID。 ,MS.PO_DISTRIBUTION_ID、MS.NEED_BY_DATE、MS.RECEIPT_DATE、
--MS.EXPECTED_DELIVERY_DATEはクリアされます
3. POが完全に受信されると、mtl_supplyの元のsupply_type_code=POが変更されます。 b. --購入時 注文受付後、MTL_SUPPLYのsupply_type_code=POがsupply_type_code=RECEIVINGに変更されます
--同時にMS.SHIPMENT_HEADER_ID、MS.SHIPMENT_LINE_ID、MS. RCV_TRANSACTION_ID、ヘッダー情報、明細情報、および
--rcv_transactionは、POの特定の行を部分的に受信した場合、mtl_supply
aの変更を出荷に格納します。 、受信ラインの元のsupply_type_code=POはsupply_type_code=RECEIVING
5に変更されます。POが検査されると、mtl_supplyの変更内容が変化します
a。POが検査された後、受入ラインの元のsupply_type_code=RECEIVINGは変更されません
。 6. PO パーツが倉庫に置かれると、mtl_supply に何が起こりますか? すべての PO パーツが倉庫に置かれると、mtl_supply の行レコードはどうなりますか?削除され、購入注文のすべての行レコードは、すべてがデータベースに配置されたときに削除されます。 PRL
ここで、prh.requisition_header_id = prl.requisition_header_id
およびprh.requisition_header_id = 662
およびprh.authorization_status= 'APPROVED'
--承認された発注書
SELECT ph.po_header_id,pl.PO_LINE_ID,phメント1、博士*
Po_Lines_all pl,Po_Headers_All ph
から、pl.PO_HEADER_ID=ph.po_header_id
/* および ph.po_header_id = 41526*/
および ph.authorization_status= 'APPROVED'
および NVL(ph.cancel_flag, 'N')< >'Y'
および ph.creation_date>=trunc(sysdate)
-- Receive
select *
from RCV_SHIPMENT_HEADERS rsh,
rcv_shipment_lines rsl
where rsh.shipment_header_id=rsl.shipment_header_id
and rsh gt;=trunc( sysdate)
and rsh.receipt_num='185631'
select *
from rcv_transactions rt
wherert.transaction_id=870339
trm説明は次のとおりです
MTL_SUPPLY は組織への入荷情報を格納します
このテーブルは、ソースの 1 つを形成します。在庫の需要供給フォーム。
このテーブルには、次の 4 つの異なるタイプの供給があります:
1) 承認された購買依頼
2) 承認された発注書
3) サプライヤーからの出荷
4) 別の組織からの移動中の出荷
タイプ 3 および4 は、
INTRANSIT_OWNING_ORGANIZATION_ID 列にデータが存在することで区別できます。これは、輸送中のアイテムの所有権を識別する
、出荷供給がベンダーからのものであることを意味します。
この情報は、適切な ATP 情報を取得するために、利用可能な約束ルーチンによって使用されます。
輸送中の品目の数量もテーブル内で追跡されます。
.
MTL_SUPPLY のレコードは、購買依頼
または PO を承認するたびに作成されます。移動中出荷を作成します。購買依頼が承認されると、1 つの購買依頼明細ごとに REQ タイプのレコードが 1 つ作成されます。
PO が承認されると、PO 配分ごとに PO タイプのレコードが 1 つ作成され、出荷明細ごとに 1 つのレコードが作成されます。
出荷の作成時に作成されます。
.
MTL_SUPPLY内のレコードは、存在するたびに再作成されます
受け取りへの返品、ベンダーへの返品、
注文書のキャンセルなどのトランザクション。
.
ドキュメントのステータスを未承認に変更するたびに、MTL_SUPPLY のレコードが削除されます。たとえば、明細と出荷数量を変更する場合、PO には承認が必要になります。
そのような PO が再承認されると、
新しい数量に対して PO 供給が再作成されます。
.
REQ 供給レコードの供給タイプ コードは、
購買依頼が自動作成されるたびに PO に変更されます。同様に、PO が完全に受信されると、供給タイプ コードは PO から RECEIVING に変更されます。発注書が
部分的に受け取られた場合、供給タイプ コード
RECEIVING を持つ供給が、受け取った数量に対して作成されます。領収書
が配達されると、RECEIVING 供給は削除されます。 SHIPMENT 供給は、PO 供給と同じように動作します。
MTL_SUPPLY には、MTL_SUPPLY_T という名前のデータベース トリガーがあります。
このトリガーは、
MTL_SUPPLY でレコードの挿入、更新、または削除時に起動します。 MRP_RELIEF_INTERFACE テーブルにレコードを挿入します