Oracle Purchasingユーザーズ・ガイド リリース12 E06013-01

目次

前へ

次へ

調達ワークフロー

調達ワークフローの概要

Oracle Purchasingでは、Oracle Workflowテクノロジを使用して購買依頼と発注の承認、発注とリリースの自動作成、発注変更（特に変更に必要な追加承認）、通知および受入確認を処理します。ワークフローは、これらの調達アクティビティを自動化する基礎となるテクノロジです。Oracle Workflowにはグラフィカル・ユーザー・インタフェースが用意されており、これらの調達ワークフロー・プロセスをビジネス・ニーズにあわせて変更できます。

Oracle Purchasingには、次のワークフローが用意されています。

• 発注勘定科目ジェネレータ・ワークフロー: 発注とリリースの経過勘定、予算勘定、借方勘定および差異勘定を自動的に生成します。関連項目: Oracle Purchasingでの勘定科目ジェネレータの使用方法。

• PO購買依頼勘定科目ジェネレータ・ワークフロー: 購買依頼の経過勘定、予算勘定、借方勘定および差異勘定を自動的に生成します。関連項目: Oracle Purchasingでの勘定科目ジェネレータの使用方法。

• 購買依頼の承認ワークフロー: 購買依頼を承認します。関連項目: 購買依頼承認ワークフロー。

• 発注承認ワークフロー: 発注を承認します。関連項目: 発注承認ワークフロー。

• 変更オーダー・ワークフロー: 手動による再承認を必要とする発注変更と、自動的に再承認される発注変更を管理します。変更オーダー・ワークフローは、実際には発注承認ワークフローに含まれるワークフロー・プロセスのグループです。関連項目: 変更オーダー承認のワークフロー・プロセス。

• 発注文書の作成ワークフロー: 発注とリリースを自動的に作成します。関連項目: 発注およびリリースの作成ワークフロー。

• 発注受入確認ワークフロー: 発注を受け入れたことを示す受入通知を依頼者または購買担当に送信します。関連項目: 受入確認ワークフロー。

• 購買文書用の発注送信通知ワークフロー: 未完了、否認済または要再承認の文書を検索し、文書のステータスに該当する担当に通知を送信します。関連項目: 通知の送信ワークフロー。

• 発注カタログの価格許容範囲超過通知ワークフロー: 購買文書オープン・インタフェースを介して送信された価格/販売カタログ情報に含まれる価格引上げが、設定した価格許容範囲を超えている場合に、購買担当に通知を送信します。関連項目: 価格/販売カタログ通知ワークフロー。

• 調達プロセス・ワークフロー: Oracle Purchasingで該当するウィンドウを起動し、表示される指示に従って調達プロセスを実行できるようにします。関連項目: プロセス・ナビゲータ・ワークフロー。

• 発注承認エラー・ワークフロー: 発注承認ワークフローの使用時に発生するエラーのトラブルシューティングを行います。関連項目: 発注承認エラー・ワークフロー。

関連項目

カスタマイズのガイドライン

カスタマイズのガイドライン

Oracle Purchasingのワークフローをカスタマイズする際に従う必要のある、重要なガイドラインの一部を次に示します。

アクセス・レベル

Oracle Workflow Builderでは、調達ワークフローの一部のアクティビティがカスタマイズできないようにロックされており、他のアクティビティはビジネス・ニーズにあわせて変更できるようにロックされていません。アクセス・レベルを変更してロックされているアクティビティを変更しないでください。

アクセス・レベルの詳細は、『Oracle Workflow開発者ガイド』のOracle Workflowのアクセス保護の概要に関する項、および『Oracle Workflow管理者ガイド』のオブジェクトへのアクセス許可の設定に関する項を参照してください。

バックアップとテスト

カスタマイズしたワークフローは、実際のデータベースにアップロードする前に、必ずテスト・データベース上でバックアップを作成してテストしてください。Oracle Purchasingの各ワークフローに関する各項には、Oracle Purchasingに用意されているデフォルト・ワークフローを変更する必要があるか、または新規に作成できるかが記載されています。カスタマイズしたワークフローの保存、バックアップおよびアップロードの詳細は、『Oracle Workflow開発者ガイド』を参照してください。

アップグレードのサポート

Oracle Purchasingの将来のアップグレードには、Oracle Purchasingワークフローのアップグレードが含まれている可能性があります。ワークフローをカスタマイズする際には、カスタマイズを将来のアップグレードから保護するかどうかを考慮してください。詳細は、『Oracle Workflow開発者ガイド』を参照してください。

ワークフロー・モニター

ワークフロー・モニターを使用すると、ワークフローの進行状況を監視できます。 関連項目: 『Oracle Workflowユーザーズ・ガイド』のワークフロー監視の概要に関する項。

ガイドライン

Oracle Workflowマニュアルに記載されている情報とともに、これらのガイドラインに従うことが重要です。また、カスタマイズ可能なアクティビティとカスタマイズ不可のアクティビティのリストと、ワークフロー特有の他の推奨事項については、Oracle Purchasingの各ワークフローに関する項を参照してください。「項目タイプの定義」Webページを使用して、ワークフローの各アクティビティの詳細情報を抽出することもできます。関連項目: 『Oracle Workflow開発者ガイド』の項目タイプの定義に関する項。

関連項目: 『Oracle Workflow開発者ガイド』のOracle Workflowサポート方針に関する項

属性

変更できるのは、各Oracle Purchasingワークフローに関する項にカスタマイズ可能として記載されている属性のみです。

プロセス

カスタマイズ可能なプロセスを変更する場合は、データベース内のデータの整合性を維持するために基本的なフローをそのまま保つことが重要です。たとえば、承認ワークフローの「文書チェック」サブプロセスの「文書は完了していますか?」関数アクティビティを削除またはバイパスしないでください。この関数アクティビティを削除またはバイパスすると、データベース表に対する不完全データの挿入が許可される可能性があります。ただし、表へのデータ挿入を許可する前に、付加的なチェック（プロセスまたは関数アクティビティ）を追加することはできます。

カスタマイズ可能なプロセスを変更するには、そのフローの一部を置き換える方法と、新しい関数アクティビティを追加する方法があります。どちらの場合も、次のことに注意してください。

• デフォルト・プロセスのデフォルト関数アクティビティによって設定される属性は、デフォルト関数アクティビティを独自のものに置き換えた場合も設定される必要があります。関数アクティビティがSetItemAttr文を使用している場合、その関数アクティビティは後で他の関数アクティビティに使用される属性を設定します。したがって、新しい関数アクティビティも同じ属性を設定する必要があります。また、 SetItemUserKey文およびSetItemOwner文があれば、それも保存する必要があります。（カスタマイズの内容によっては、GetItemAttr文も保存してください。）

• デフォルト・プロセスによって保守されるデータベースのステータスは、カスタマイズ後のプロセスでも保守する必要があります。プロセス内の関数アクティビティがUpdate文またはInsert Into文を使用している場合、その関数アクティビティはデータベース内で行を更新または挿入します。したがって、新しい関数アクティビティでも同じデータベース・ステータスを保守する必要があります。

SetItemAttr文、GetItemAttr文、SetItemUserKey文、SetItemOwner文、Insert Into文またはUpdate文を使用するワークフロー関数アクティビティのリストを取得するには、PL/SQLスクリプトpowfcust.sqlを実行します。

重要: このスクリプトを実行すると、関数アクティビティの削除による影響を確認できます。ただし、プロセスをカスタマイズする前に、必ず影響を独自に分析してください。

powfcust.sqlを実行する手順は、次のとおりです。

1. PL/SQLストアド・プロシージャが格納されているディレクトリに移動します。

    cd $PO_TOP/sql
   
   
   
   

2. SQLプロンプトから次のスクリプトを起動します。

    @powfcust.sql
   
   
   
   

3. プロンプトに対して、スクリプトの実行対象とするワークフロー項目タイプの内部名を入力するか、またはALLと入力してOracle Purchasingの全ワークフローに対してスクリプトを実行します。

   Oracle Purchasingの内部ワークフロー名は、次のとおりです。

   ワークフロー	内部名
   発注勘定科目ジェネレータ	POWFPOAG
   PO購買依頼勘定科目ジェネレータ	POWFRQAG
   発注承認	POAPPRV
   購買依頼の承認	REQAPPRV
   発注文書の作成	CREATEPO
   発注受入確認	PORCPT
   購買文書用の発注送信通知	APVRMDER
   発注カタログの価格許容範囲超過通知	POPRICAT

   このスクリプトを実行すると、SetItemAttr文、GetItemAttr文、SetItemUserKey文、SetItemOwner文、Insert Into文またはUpdate文を使用するワークフローの各関数アクティビティが表示されます。

   このスクリプトを実行すると、関数アクティビティの削除による影響を確認できます。プロセスをカスタマイズする前に、必ず影響を独自に分析してください。

通知

通知に返信コードが含まれている場合は、カスタマイズした通知の「結果タイプ」がワークフロー・ダイアグラムでの遷移と一致していることを確認してください。関連項目: 『Oracle Workflow開発者ガイド』の通知アクティビティの作成に関する項。関連項目: 『Oracle Workflow開発者ガイド』のメッセージ結果に関する項。関連項目: 『Oracle Workflow開発者ガイド』のメッセージの作成に関する項。

関数アクティビティ

通常、関数アクティビティは変更できませんが、ワークフローに関するドキュメントでデフォルト関数アクティビティを削除しないように記載されている場合を除き、独自の関数アクティビティに置き換えることは可能です。

関数アクティビティを置き換えると、それを含んでいるプロセスを変更することになります。プロセス内のデフォルト関数アクティビティを独自作成した関数アクティビティに置き換える場合は、次のことに注意する必要があります。

• 新しい関数アクティビティの結果タイプは、デフォルト・アクティビティの結果タイプと一致する必要があります。つまり、Oracle Workflow Builderにおける関数アクティビティの「結果タイプ」（「Yes/No」結果タイプなど）は、その関数アクティビティの対応するPL/SQLプロシージャで指定する結果タイプと一致する必要があります。また、関数アクティビティおよび対応するPL/SQLプロシージャに2つの結果（「Yes」と「No」など）がある場合は、ワークフロー・ダイアグラム内に2つの対応する遷移が（「Yes」に1つと「No」に1つ）存在することを確認してください。プロセスの結果タイプと遷移を変更する場合は、特別な遷移やチェックを削除またはバイパスしないように注意する必要があります。

• 前述の「プロセス」と同様に、デフォルト関数アクティビティにより設定されていた属性は、カスタマイズした関数アクティビティでも設定する必要があります。

• 前述の「プロセス」と同様に、デフォルト関数アクティビティにより維持されていたデータベースの状態は、カスタマイズした関数アクティビティでも維持する必要があります。

参照タイプ

カスタマイズ可能な参照タイプを変更する場合は、その参照タイプを使用するすべてのアクティビティを変更対象とみなしてください。たとえば、参照タイプを「Yes/No」から他のタイプに変更すると、その参照タイプを使用するアクティビティについても、「結果タイプ」を「Yes/No」から新規作成した参照タイプに変更する必要があります。関連項目: 『Oracle Workflow開発者ガイド』の参照タイプに関する項。

関連項目

Oracle Purchasingでの勘定科目ジェネレータの使用方法

発注承認ワークフロー

購買依頼承認ワークフロー

変更オーダー承認のワークフロー・プロセス

「発注およびリリースの作成」ワークフロー

受入確認ワークフロー

通知の送付ワークフロー

価格/販売カタログ通知ワークフロー

勘定科目ジェネレータでのワークフロー・モニターの使用方法

発注文書作成ワークフローでのワークフロー・モニターの使用方法

プロセス・ナビゲータ・ワークフロー

Oracle Purchasingでの勘定科目ジェネレータの使用方法

この項では、Oracle Purchasingにおけるデフォルトの勘定科目ジェネレータ・プロセスの使用方法とカスタマイズ方法について説明します。

Oracle Purchasingの勘定科目ジェネレータは、Oracle Workflowを利用します。Oracle Workflow Builderを介して勘定科目ジェネレータのプロセスを表示し、カスタマイズできます。また、Oracle Workflow Monitorを介して勘定科目生成をモニターすることも可能です。関連項目: 『Oracle Workflowユーザーズ・ガイド』。

すべての発注、購買依頼およびリリースは会計配分を必要とします。Oracle Purchasingでは、文書配分ごとに借方勘定、予算勘定（予算管理を使用している場合）、経過勘定および差異勘定が自動的に作成されます。

Oracle Purchasingには、次の操作に必要な機能が用意されています。

• 会計配分の自動作成による正確さの向上と文書生成の高速化

• 購買の借方計上勘定を指定する責務からの購買担当、依頼者および文書作成者の解放

• ビジネス・ルールにあわせた勘定科目ジェネレータの勘定科目作成ルールのカスタマイズ

• 資金会計の実行（公共部門インストールの場合）

関連項目: 『Oracle Applicationsフレックスフィールド・ガイド』の勘定科目ジェネレータの概要に関する項

勘定科目ジェネレータの使用方法の決定

次の各項に従って、デフォルトの勘定科目ジェネレータ・プロセスが会計処理要件を満たしているかどうかを評価してください。

この決定内容により、実装チームが実行することが必要な設定ステップが決まります。

勘定科目ジェネレータの使用方法の決定

リリース10では、フレックスビルダーを使用する複数のOracle Applications製品で特定の勘定取引の勘定科目コード組合せが導出されていました。リリース11では、フレックスビルダーが勘定科目ジェネレータに置き換えられており、実装チームにとっては柔軟性が向上し、Oracle Workflowとのユーザー・インタフェースも向上しています。

以前のリリースで勘定科目組合せを生成するためにフレックスビルダーをカスタマイズしていた場合は、「フレックスビルダ・ルールを使った勘定科目の生成」プロセスを使用するとフレックスビルダーの設定を自動的に複製できます。事前定義済のフレックスビルダー・ルールを変更したり、勘定科目ジェネレータをカスタマイズする必要はありません。「フレックスビルダ・ルールを使った勘定科目の生成」プロセスでは、勘定科目を生成するために、アップグレード中に生成された適切な関数がコールされます。

注意: リリース10でフレックスビルダーを使用していても、デフォルト構成をカスタマイズしていなかった場合は、リリース11でデフォルトの勘定科目ジェネレータ・プロセスを使用して、フレックスビルダーでのデフォルト割当てと同じ結果を得ることができます。

Oracle Purchasingの初回実装時には、Oracle Purchasingでどのように勘定科目ジェネレータを使用して会計フレックスフィールド・コード組合せを作成するかを検討する必要があります。関連項目: Oracle Purchasingでの勘定科目ジェネレータの機能。一意の会計フレックスフィールド体系を使用する元帳ごとに、デフォルトの勘定科目ジェネレータ・プロセスが適切かどうかを検討してください。体系と元帳ごとに、次のいずれかを選択できます。

• デフォルトの勘定科目ジェネレータ・プロセスの使用

  • デフォルト経過勘定の生成

  • デフォルト予算勘定の生成

  • デフォルト借方勘定の生成

  • デフォルト差異勘定の生成

  • デフォルトの搬送先借方勘定の生成

  • デフォルトの搬送先差異勘定の生成

• デフォルトの勘定科目ジェネレータ・プロセスのカスタマイズ

デフォルトを使用する場合、設定ステップは不要です。デフォルト・プロセスは、ニーズの変化に応じて後から更新することも可能です。

勘定科目ジェネレータ使用の前提条件

Oracle Purchasingの本番データベースで勘定科目ジェネレータを使用して発注、リリースおよび購買依頼配分用の勘定科目を作成する前に、次のステップを完了しておく必要があります。

重要: これらのステップは、営業単位ごとに実行する必要があります。

1. 元帳ごとに会計フレックスフィールド体系を定義します。

2. フレックスフィールド・セグメント値と検証ルールを定義します。

3. Oracle Workflowを設定します。

4. デフォルトの勘定科目ジェネレータ・プロセスを使用するか、または会計処理のニーズにあわせてカスタマイズする必要があるかを選択します。

5. 元帳ごとに次のいずれかを実行します。

   • デフォルトの勘定科目ジェネレータ・プロセスを使用するように選択します。

   • デフォルトの勘定科目ジェネレータ・プロセスをカスタマイズし、カスタマイズをテストし、必要に応じてフレックスフィールド体系用のプロセスを選択します。

関連項目

Oracle Purchasingのデフォルトの勘定科目ジェネレータ・プロセス

Oracle Purchasing用勘定科目ジェネレータのカスタマイズ

Oracle Purchasingでの勘定科目ジェネレータの機能

Oracle Purchasingでのデフォルトの勘定科目ジェネレータ処理では、配分の「費用」、「在庫」または「製造現場」賦課先タイプに基づいて、発注、リリースおよび購買依頼配賦の借方、予算、経過勘定および差異勘定科目が作成されます。Oracle Purchasingでは、勘定科目ジェネレータを使用して常にこれらの勘定科目を作成します。この機能を無効にはできません。

集中調達機能を使用する場合、勘定科目ジェネレータでは、調達組織と搬送先組織の間の会計取引を記録するための2つの新規勘定科目も作成されます。一方は搬送先借方勘定科目で、他方は搬送先差異勘定科目です。この2つの勘定科目が作成されて使用されるのは、搬送先組織が調達組織とは異なる営業単位にあり、2つの組織間の取引フローが定義済の場合のみです（2つの営業単位が異なる会計帳簿を使用している場合は、取引フローを定義する必要があることに注意してください）。たとえば、集中調達シナリオで、ユーザーがある営業単位内で発注を作成し、別の営業単位に納入する必要があるとします。この場合、2つの組織（営業単位）間の所有権移動を記録するための会計取引（商品の受入時に作成）が作成されます。これらの勘定科目は、不要であれば作成されません。

在庫借方勘定科目作成の場合、勘定科目ジェネレータでは配分について入力する項目と保管場所に基づいて、資産購入と費用購入がさらに区別されます。費用品目を選択すると、勘定科目ジェネレータでは保管場所が無視され、費用借方勘定科目が作成されます。資産品目を選択すると、保管場所が評価され、費用借方勘定科目と資産借方勘定科目のどちらを作成するかが決定されます。

注意: 保管場所を費用または資産として分類するには、Oracle Inventoryの「保管場所」ウィンドウで「資産保管場所」チェック・ボックスを選択するか、選択を解除します。品目を費用または資産として分類するには、「マスター品目」ウィンドウの「原価計算」セクションで「在庫資産価額」チェック・ボックスを選択するか、選択を解除します（このウィンドウには、Oracle InventoryまたはOracle Purchasingからアクセス可能です）。

勘定科目ジェネレータでは、配分搬送先タイプに基づいてソース勘定科目が検索され、指定したフィールドから搬送先会計フレックスフィールドにコード組合せ全体（完全な会計フレックスフィールド）がコピーされます。デフォルトのOracle Purchasingプロセスでは、個別フレックスフィールド・セグメントは作成されません。

たとえば、「費用」搬送先タイプの配分用に経過勘定を移入するために、勘定科目ジェネレータでは、アプリケーション設定の一部としてOracle Purchasingウィンドウで指定した費用と対応する経過勘定が検索され、文書の経過勘定フレックスフィールドにコピーされます。

例外は、最初の2つのステップで勘定科目ジェネレータにより借方勘定科目を導出できない場合です。その場合、勘定科目はHR従業員レコードから取得され、品目カテゴリに基づいて個別セグメントが置換されます。これは、Oracle Purchasingで単発品目を使用する場合の一般的なシナリオです。

次のマトリックスに、勘定科目ジェネレータで配分の搬送先タイプに基づいて借方勘定、予算勘定、経過勘定および差異勘定を作成するために参照されるソース・フィールドを示します。

水平軸は、勘定科目ジェネレータによりOracle Purchasing内で参照されるソース勘定科目の指定に使用するウィンドウを示します。垂直軸は、勘定科目ジェネレータにより作成される勘定科目タイプごとに可能な搬送先タイプを示します。また、「付加的考慮事項」は、上位と下位の間のアクセスの一部として適用されます。マトリックスの本体は、参照勘定科目の入力に使用するフィールドを示します。

特定の勘定科目/搬送先タイプの組合せについて複数のオプションが示されている場合、勘定科目ジェネレータでは、「付加的考慮事項」に示す条件に該当するかぎり、マトリックスの「順序」に1と示された主要ソース勘定科目が検索されます。これは、付加的条件が複数存在する場合があるため、順序1のソース勘定科目も複数存在する可能性があることを意味します。最初に該当する付加的条件が、試行されるソースとなります。この参照勘定科目を使用できない場合、または入力した配分情報に適切でない場合は、2として示されたソースが試行され、参照勘定科目が見つかるまで検索が続行され、見つからなければ失敗します。マトリックスには、勘定科目が見つかるか、勘定科目ジェネレータが勘定科目の検出に失敗した場合に適用可能な上書き条件が示されています。これらのエントリは、数値のかわりにOで示されています。上書きの場合は、作成済の勘定科目が優先されます。

ヒント: ビジネスに適切な詳細レベルでソース勘定科目を指定すると、設定を最小限に抑えることができます。たとえば、「在庫」（費用）搬送先タイプの借方勘定ソースは、保管場所、品目または組織レベルで指定できます。組織レベルの勘定科目でビジネス・ニーズに十分に対応できる場合、品目または保管場所レベルの勘定科目を指定する必要はありません。

「製造現場」搬送先タイプの場合、勘定科目ジェネレータでは最初にOracle Enterprise Asset Management（EAM）ルールが適用されます。勘定科目が見つからなければ、外注加工製造オーダーに関連付けられている生産資源原価要素に基づいて借方勘定科目が作成されます。この場合、勘定科目ジェネレータでは、5つの可能なソース勘定科目のうち1つが選択されます。他の搬送先タイプの場合のように選択肢の階層が段階的に検索されることはありません。また、予算引当を使用していても、勘定科目ジェネレータで製造現場配分用の予算勘定が作成されることはありません。Oracle Purchasingでは、外注加工の購買に対する引当は実行されません。

重要: 勘定科目ジェネレータで借方勘定を作成できない場合、文書に借方勘定を手動で作成する方法と、独自のビジネス・ルールに基づいて費用搬送先借方勘定を作成するように、カスタムの勘定科目ジェネレータ機能を設計する方法があります。

勘定科目ジェネレータにより作成される経過勘定、予算勘定または差異勘定の編集はできませんが、コミットされていない費用配分の借方勘定は上書きまたは指定できます。この場合、勘定科目ジェネレータにより作成される借方勘定を編集する方法と、文書の「デフォルト」リージョンでデフォルト借方勘定を指定する方法があります。デフォルトの借方勘定を指定すると、勘定科目ジェネレータにより提供される費用借方勘定が常に上書きされます。

勘定科目の作成時期とロジスティクス

「購買依頼」、「発注」および「リリース」ウィンドウでの「費用」および「在庫」搬送先の場合は、配分の「借方勘定」フィールドにナビゲートするか、ウィンドウ内での明示的または暗黙的なコミットにより配分の作成に十分な情報がOracle Purchasingに提供されると、勘定科目ジェネレータにより勘定科目が作成されます。「製造現場」搬送先の場合は、「外注加工」リージョンに必須データをすべて入力して文書の「配分」リージョンに戻るかコミットすると、コードが作成されます。

ウィンドウの作成順序は次のとおりです。

1. チャージ

2. 予算

3. 経過

4. 差異

5. 搬送先借方

6. 搬送先差異

各勘定科目は、以降の作成に可能なソース値として提供されます。たとえば、予算ルールでは、借方勘定が可能な値として受け入れられ、「費用」搬送先タイプの場合は借方勘定値が「予算勘定」フィールドにコピーされます。経過勘定ルールでは、借方勘定値と予算勘定値の両方が受け入れられます。また、差異勘定ルールでは、借方、予算および経過の各勘定値が可能なソースとして受け入れられます。

勘定科目ジェネレータが経過勘定、差異勘定または予算勘定を作成できない場合、これらのフィールドに欠落値を手動入力することはできません。勘定科目ジェネレータ失敗の原因となった問題を識別して解決する必要があります。勘定科目ジェネレータが借方勘定または予算勘定を作成できない場合、搬送先タイプが「費用」であれば、欠落値を手動で指定できます。予算勘定ルールと差異勘定ルールでは「費用」搬送先タイプの借方勘定値が使用されるため、勘定科目ジェネレータは初回の作成試行中に検索できなければ、借方勘定を手動で入力した直後にこれらの勘定を作成しようとします。

文書更新後は勘定科目ジェネレータによる再作成は実行されない

以前のリリースの機能との一貫性を維持するために、勘定科目ジェネレータにより文書の勘定科目が正常に作成された後は、文書を更新しても再作成は試行されません。たとえば、依頼者に基づいて費用購買用の購買依頼借方勘定を生成するカスタム・プロセスを作成し、勘定科目ジェネレータにより借方勘定が作成された後に依頼者を変更した場合、再作成は試行されません。

購買依頼インポートでは、借方勘定、予算勘定、経過勘定または差異勘定の作成に勘定科目ジェネレータは使用されません。独自作成したカスタム・プロセスは、このユーティリティでは使用できません。

関連項目

Oracle Purchasing用勘定科目ジェネレータのカスタマイズ

Oracle Purchasingのデフォルトの勘定科目ジェネレータ・プロセス

勘定科目ジェネレータとワークフロー・モニターの併用

Oracle Purchasing用勘定科目ジェネレータのカスタマイズ

Oracle Purchasingには、デフォルトの勘定科目ジェネレータ・プロセスが用意されています。デフォルトでは会計処理要件が満たされない場合は、Oracle Workflow Builderを使用してデフォルト・プロセスをカスタマイズできます。

Oracle Purchasingのワークフローを使用または変更する前に、このマニュアルの冒頭の設定情報を参照してください。

勘定科目ジェネレータの全般的な機能の詳細は、『Oracle Applicationsフレックスフィールド・ガイド』の勘定科目ジェネレータのカスタマイズに関する項を参照してください。

ワークフローをカスタマイズするには、Oracle Workflow Builderを使用します。ワークフローをカスタマイズした場合、そのワークフローの影響を受けるのは、カスタマイズ後に作成する文書のみです。

ワークフロー・モニターを使用すると、ワークフロー・プロセス内の特定の文書の位置をたどることができます。勘定科目ジェネレータによる勘定科目の作成中に問題が発生した場合は、「勘定科目ジェネレータ: デバッグ・モードで実行」プロファイル・オプションを「Yes」に設定することで問題を調べることができます（パフォーマンスを維持するために、確認後は必ず「No」に戻してください）。関連項目: 勘定科目ジェネレータとワークフロー・モニターの併用。

Oracle Workflow Builderでワークフローを表示する手順は、次のとおりです。

1. 「ファイル」メニューから「オープン」を選択して、データベースに接続します。

   関連項目: 『Oracle Workflow開発者ガイド』の項目タイプのオープンと保存に関する項

   発注に使用する勘定科目ジェネレータ・ワークフローの表示名は「発注勘定科目ジェネレータ」です。ワークフロー定義ファイル名はpoxwfpag.wftです。

   購買依頼に使用する勘定科目ジェネレータ・ワークフローの表示名は「PO購買依頼勘定科目ジェネレータ」です。ワークフロー定義ファイル名はpoxwfrag.wftです。

   

2. データ・ソースを拡張し、そのデータ・ソース内で「勘定科目ジェネレータ」項目タイプのブランチを拡張します。

3. 「発注勘定科目ジェネレータ」ブランチ内の「プロセス」ブランチを拡張し、プロセス・アクティビティをダブルクリックしてダイアグラムを表示します。

新規カスタム処理の作成

発注勘定科目ジェネレータまたはPO購買依頼勘定科目ジェネレータ・ワークフローをカスタマイズする場合は、Oracle Purchasingに用意されているデフォルト（オリジナル）ワークフローをカスタマイズする必要があります。Oracle Purchasingの発注承認、購買依頼の承認および発注文書の作成ワークフローとは異なり、「勘定科目生成処理」ウィンドウを介してアプリケーション自体からコールできる勘定科目ジェネレータ・ワークフローは1つのみです。「文書タイプ」ウィンドウ内の他のワークフローのように個別カスタマイズを選択することはできません。したがって、デフォルトの勘定科目ジェネレータ・ワークフローをカスタマイズする必要があります。カスタマイズのテスト中に必要に応じて元に戻せるように、バックアップを用意してください。

必要な変更

ビジネス要件にあわせたカスタマイズを必要とする場合を除き、発注勘定科目ジェネレータまたはPO購買依頼勘定科目ジェネレータ・ワークフローに必須の変更はありません。関連項目: 勘定科目ジェネレータの使用方法の決定。

サポートされるカスタマイズとサポートされないカスタマイズ

この項では、発注勘定科目ジェネレータおよびPO購買依頼勘定科目ジェネレータ・ワークフローの両方について、変更可能な内容と変更不可の内容を説明します。変更可能な内容については、カスタマイズする際に注意を必要とする重要なガイドラインについても説明します。

ワークフローのカスタマイズ方法に関する重要情報は、『Oracle Workflow開発者ガイド』を参照してください。

カスタマイズの詳細は、この章の「デフォルト勘定科目ジェネレータ・プロセス」以降の各項を参照してください。これらの項では、発注勘定科目ジェネレータおよびPO購買依頼勘定科目ジェネレータ・ワークフローのメイン・プロセスのコンポーネントについて説明しています。まだ参照していない場合は、「カスタマイズのガイドライン」も参照してください。

重要: 以降の各項で、特定のワークフロー・オブジェクトがカスタマイズ可能オブジェクトのリストに記載されていない場合は、アクセス・レベルに関係なく変更しないでください。

属性

「発注勘定科目ジェネレータ」または「PO購買依頼勘定科目ジェネレータ」の属性は、いずれも変更できません。

プロセス

プロセスを変更する場合は、基本的なフローを維持することが重要です。たとえば、「費用借方勘定の作成」サブプロセスの「費用勘定科目IDを取得」関数アクティビティでは、「一時アカウントID」項目属性に作成対象の勘定科目のコード組合せID（CCID）が設定されます。この属性は、「勘定科目IDから値をコピー」関数アクティビティで連結セグメントをフェッチするために使用されます。したがって、「費用勘定科目IDを取得」関数アクティビティを独自の関数アクティビティに置き換える場合、新規の関数アクティビティでも「一時アカウントID」項目属性を設定する必要があります。

プロセスを変更するには、そのフローの一部を置き換える方法と、新しい関数アクティビティを追加する方法があります。どちらの場合も、次のことに注意してください。

• デフォルト・プロセスのデフォルト関数アクティビティによって設定される属性は、デフォルト関数アクティビティを独自のものに置き換えた場合も設定される必要があります。つまり、そのプロセス内の関数アクティビティがSetItemAttr文を使用している場合、その関数アクティビティは後で他の関数アクティビティに使用される属性を設定します。したがって、新しい関数アクティビティも同じ属性を設定する必要があります。また、 SetItemUserKey文およびSetItemOwner文があれば、それも保存する必要があります。カスタマイズの内容によっては、GetItemAttr文も保存してください。

• デフォルト・プロセスが保守しているデータベースの状態は、カスタマイズしたプロセスでも保守する必要があります。つまり、カスタマイズしたプロセスの関数アクティビティでUpdate文またはInsert Into文を使用する場合、その関数アクティビティは、データベースの行を更新または挿入します。したがって、新規の関数アクティビティは、データベースを同じ状態に保守する必要があります。

  SetItemAttr文、GetItemAttr文、SetItemUserKey文、SetItemOwner文、Insert Into文またはUpdate文を使用するワークフロー関数アクティビティのリストを取得するには、PL/SQLスクリプトpowfcustを実行します。このスクリプトの実行手順は、「カスタマイズのガイドライン」を参照してください。

「発注勘定科目ジェネレータ」および「PO購買依頼勘定科目ジェネレータ」の両方で、次のプロセスをビジネス・ニーズに応じて変更できます。

• デフォルト経過勘定の生成

• デフォルト予算勘定の生成

• デフォルト借方勘定の生成

• デフォルト差異勘定の生成

• 費用借方勘定の作成

• 在庫予算勘定の作成

• 在庫借方勘定の作成

• 費用プロジェクト経過勘定の作成

• 費用プロジェクト予算勘定の作成

• 費用プロジェクト借方勘定の作成

• 費用プロジェクト差異勘定の作成

• 製造現場借方勘定の作成

• 差異勘定の借方勘定を取得

• 組織から差異勘定を取得

「発注勘定科目ジェネレータ」または「PO購買依頼勘定科目ジェネレータ」の次のプロセスは変更できません。

• デフォルト勘定科目の生成

• フレックスビルダ・ルールを使った勘定科目の生成

• フレックスビルダ・ルールを使った借方勘定の生成

• フレックスビルダ・ルールを使った予算勘定の生成

• フレックスビルダ・ルールを使った経過勘定の生成

• フレックスビルダ・ルールを使った差異勘定の生成

関数アクティビティ

「発注勘定科目ジェネレータ」または「PO購買依頼勘定科目ジェネレータ」の関数アクティビティは、いずれも変更できません。ただし、「エラー・メッセージの設定」関数アクティビティは、その属性をOracle Workflow Builderで変更することで変更可能です。関連項目: 「エラー・メッセージの設定」関数アクティビティを使用する手順。

一部の関数アクティビティは、独自の関数アクティビティに置き換えることができます。関数アクティビティを置き換える場合は、それを含んでいるプロセスを変更します。関連項目: 「プロセス」の勘定科目ジェネレータ・プロセスのカスタマイズのガイドライン。

プロセスのデフォルト関数アクティビティを独自作成した関数アクティビティに置き換える場合は、次の点に注意してください。

• 新しい関数アクティビティの結果タイプは、デフォルト・アクティビティの結果タイプと一致する必要があります。つまり、Oracle Workflow Builderにおける関数アクティビティの「結果タイプ」は、その関数アクティビティの対応するPL/SQLプロシージャで指定する結果タイプと一致する必要があります（「Yes/No」結果タイプなど）。また、関数アクティビティおよび対応するPL/SQLプロシージャに2つの結果（「Yes」と「No」など）がある場合は、ワークフロー・ダイアグラム内に2つの対応する遷移が（「Yes」に1つと「No」に1つ）存在することを確認してください。プロセスの結果タイプと遷移を変更する場合は、特別な遷移やチェックを削除またはバイパスしないように注意する必要があります。

• 前述の「プロセス」と同様に、デフォルト関数アクティビティにより設定されていた属性は、カスタマイズした関数アクティビティでも設定する必要があります。

• 前述の「プロセス」と同様に、デフォルト関数アクティビティにより維持されていたデータベース・ステータス性は、カスタマイズした関数アクティビティでも設定する必要があります。

この関数アクティビティは、ワークフローのプロセスでは使用されませんが、カスタマイズしたエラー・メッセージを作成することが必要な場合のために用意されています。この関数アクティビティを使用して、カスタマイズしたエラー・メッセージを送信するには、次の手順を実行します。

「エラー・メッセージの設定」関数アクティビティを使用する手順は、次のとおりです。

1. Oracle Applicationsメッセージ・ディクショナリ内でメッセージを作成します。

   この関数アクティビティで使用する前に、エラー・メッセージをOracle Applicationsメッセージ・ディクショナリ内で定義する必要があります。手順については、「アプリケーション開発者」職責で「メッセージ」ウィンドウのオンライン・ヘルプを参照するか、『Oracle Applications開発者ガイド』を参照してください。

2. 「エラー・メッセージの設定」関数アクティビティを、変更するプロセスのプロセス・ダイアグラムにドラッグ・アンド・ドロップします。

3. プロセス・ダイアグラムでアクティビティを選択し、「編集」メニューから「プロパティ」を選択します。

4. 「ノード属性」リージョンで、メッセージ・ディクショナリで定義したメッセージのメッセージ名を入力します。エラー・メッセージの動的テキストを提供するトークンを1つ以上入力することもできます。

   「アプリケーション・コード」はデフォルトでPO（Oracle Purchasing）に設定されますが、他のアプリケーションでエラー・メッセージを表示する場合は変更できます。

参照タイプ

発注勘定科目ジェネレータおよびPO購買依頼勘定科目ジェネレータでは、発注標準ワークフローに用意されている次の2つの参照タイプが使用されます。これらの参照タイプは変更できません。

• 発注作業項目搬送先タイプ

• 発注WIPタイプ

標準フレックスフィールド・ワークフローに用意されているデフォルト参照タイプの詳細は、『Oracle Applicationsフレックスフィールド・ガイド』の勘定科目ジェネレータに関する項を参照してください。

カスタマイズした勘定科目ジェネレータ・プロセスの実装

「勘定科目生成処理」ウィンドウを使用して、「デフォルト勘定科目の生成」プロセスまたは「フレックスビルダ・ルールを使った勘定科目の生成」プロセスを選択し、そのプロセスを適切な会計フレックスフィールド体系および項目タイプに関連付けます。

「デフォルト勘定科目の生成」プロセスに属するカスタマイズ可能プロセスのいずれかをカスタマイズする場合、このプロセスが適切な会計フレックスフィールド体系および項目タイプに関連付けられていることを「勘定科目生成処理」ウィンドウで確認できれば、カスタマイズは有効です。

フレックスフィールド体系用プロセスの選択

1. 「システム管理者」職責に切り替えて「アプリケーション」>「フレックスフィールド」>「キー」>「勘定科目」を選択し、「勘定科目生成処理」ウィンドウにナビゲートします。

2. 「アプリケーション」フィールドにカーソルを置いて「表示」>「検索」を選択し、必要なアプリケーション、フレックスフィールド・タイトルおよび体系の組合せを選択します。

   または、「問合せ」>「実行」を実行し、「項目タイプ」列で「発注勘定科目ジェネレータ」および「PO購買依頼勘定科目ジェネレータ」項目タイプを検索します。

3. 「プロセス」フィールドで、これらの勘定科目の生成に使用するプロセス（「デフォルト勘定科目の生成」または「フレックスビルダ・ルールを使った勘定科目の生成」）を指定します。

   デフォルト・プロセスの「デフォルト勘定科目の生成」がデフォルト設定されます。

関連項目

Oracle Purchasingでの勘定科目ジェネレータの使用方法

Oracle Purchasingのデフォルトの勘定科目ジェネレータ・プロセス

勘定科目ジェネレータとワークフロー・モニターの併用

Oracle Purchasingのデフォルトの勘定科目ジェネレータ・プロセス

Oracle Purchasingには、次の勘定科目ジェネレータ・ワークフロー項目タイプが用意されており、1つ目は発注およびリリース用、2つ目は購買依頼用です。

• 発注勘定科目ジェネレータ

• PO購買依頼勘定科目ジェネレータ

各勘定科目ジェネレータ・ワークフローには、次の最上位レベル・プロセスが含まれています。

• フレックスビルダ・ルールを使った勘定科目の生成

• デフォルト勘定科目の生成

「デフォルト勘定科目の生成」は、次の4つのメイン・サブプロセスで構成されています。

• デフォルト経過勘定の生成

• デフォルト予算勘定の生成

• デフォルト借方勘定の生成

• デフォルト差異勘定の生成

他のサブプロセスは次のとおりです。

• 費用借方勘定の作成

• 在庫借方勘定の作成

• 製造現場借方勘定の作成

• 在庫予算勘定の作成

• 費用プロジェクト経過勘定の作成

• 費用プロジェクト予算勘定の作成

• 費用プロジェクト借方勘定の作成

• 費用プロジェクト差異勘定の作成

• 差異勘定の借方勘定を取得

• 組織から差異勘定を取得

各勘定科目ジェネレータには、多数の項目属性が含まれています。これらの属性は、すべてのRawパラメータと、フレックスビルダーで使用されていた一部の導出パラメータに対応しています。各勘定科目IDは、以降の作成対象勘定科目に項目属性の形式で可能なソース値として入力されます。

両方の勘定科目ジェネレータ項目タイプの項目タイプ属性を次に示します。

勘定科目ジェネレータ・ワークフロー項目タイプの属性

「デフォルト勘定科目の生成」プロセスの概要

「デフォルト勘定科目の生成」プロセスのプロパティを表示するには、そのプロセスをナビゲータ・ツリーで選択し、「編集」メニューから「プロパティ」を選択します。「デフォルト勘定科目の生成」プロセスの結果タイプは「フレックスフィールドの結果」で、プロセスの完了時に結果が「失敗」または「成功」となることを示します。これらの結果は、「標準フレックスフィールド・ワークフロー」項目タイプの「フレックスフィールドの結果」参照タイプの参照コードに対応します。

このプロセス・アクティビティは実行可能でもあります。これは、ワークフロー・エンジンのCreateProcessおよびStartProcess APIのコールによってトップ・レベル・プロセスとして実行できることを示します。

プロセス・アクティビティの「詳細」プロパティ・ページは、「デフォルト勘定科目の生成」プロセスにDEFAULT_ERRORというエラー・プロセスが関連付けられており、プロセスにエラーが発生した場合にのみ開始されることを示します。このエラーにより、「システム: エラー」項目タイプに関連付けられているDEFAULT_ERRORが開始されます。現在、このプロセスでは単に標準の「デフォルト・エラー通知」アクティビティが実行されて、エラー関連の情報が提供されます。このプロセスは、ニーズにあわせてさらにカスタマイズできます。関連項目: 『Oracle Workflow開発者ガイド』のデフォルト・エラー・プロセスに関する項。

勘定科目ジェネレータ・プロセスの開始時期の詳細は、「Oracle Purchasingでの勘定科目ジェネレータの機能」の「勘定科目の作成時期とロジスティクス」を参照してください。

「デフォルト勘定科目の生成」は、Oracle Purchasingで勘定科目を作成するデフォルト・ワークフロー・プロセスです。

ノード2では、借方勘定が文書に手動で入力済かどうかがチェックされます（たとえば、コミットされていない費用配分の借方勘定を上書きまたは指定できます）。すでに借方勘定が存在する場合、このプロセスはノード3の借方勘定生成プロセスをスキップしてノード7に進み、予算勘定が必要かどうかが判別されます。

ノード3、8、11および13では、借方勘定、予算勘定（ノード7で予算管理の使用が検出された場合）、経過勘定および差異勘定が作成されます。これらのノードは、勘定科目を作成できない場合（入力されていない勘定科目セグメントがある場合や、使用不可のセグメントが使用された場合など）、ノード4、9または14で失敗します。（この場合は、文書ウィンドウにエラーが表示されます。）

ノード5および12では、前の勘定科目について勘定科目セグメント値の生成が完了するまでワークフローの実行が一時停止されます。ノード5には、借方勘定のコード組合せ識別子（CCID）の生成に失敗した場合のために失敗オプションが用意されています。この場合にのみ、ワークフローはノード6で終了します。

「デフォルト勘定科目の生成」プロセスのアクティビティ

ここでは、「PO購買依頼勘定科目ジェネレータ」および「PO購買依頼勘定科目ジェネレータ」のすべてのプロセスとサブプロセスに使用される各アクティビティについて、アクティビティの表示名別に説明します。関数アクティビティによってコールされるPL/SQLストアド・プロシージャを除き、アクティビティのコンポーネントはすべてグラフィカルWorkflow Builderで作成できます。PL/SQLストアド・プロシージャはすべての関数アクティビティで実行されるため、Oracle RDBMS内で作成して格納する必要があります。PL/SQLストアド・プロシージャの命名規則は次のとおりです。

<PACKAGE>.<PROCEDURE> 

<PACKAGE>は全プロシージャをグループ化するパッケージの名称で、<PROCEDURE>はプロシージャ名を表します。

「項目タイプの定義」Webページを使用すると、<PACKAGE>.<PROCEDURE>名を確認できます。関連項目: 『Oracle Workflow開発者ガイド』の「項目タイプの定義」Webページに関する項。

「開始」および「終了」関数アクティビティなど、ここには記載されていない関数アクティビティがあります。これらは、「標準フレックスフィールド・ワークフロー」項目タイプに用意されている標準関数アクティビティです。これには、「コード組合せから値をコピー」および「コード組合せの検証」関数アクティビティも含まれます。これらの関数アクティビティの使用方法は、『Oracle Applicationsフレックスフィールド・ガイド』の標準フレックスフィールド・ワークフローに関する項を参照してください。

この項で説明するほとんどの関数アクティビティでは、「Oracle Purchasingでの勘定科目ジェネレータの使用方法」の表に示したのと同じ関数が実行されます。

費用項目の経過勘定

この関数アクティビティにより、費用項目の経過勘定が取得されます。

組織からの経過勘定

この関数アクティビティにより、組織から在庫品目と製造現場品目の経過勘定が取得されます。

在庫借方勘定の作成

この関数アクティビティにより、品目が費用品目であるか資産品目であるかに基づいて、在庫品目に該当する借方勘定が取得されます。

費用勘定科目

この関数アクティビティにより、費用品目の費用借方勘定が取得されます。

品目/保管場所から予算勘定を取得

この関数アクティビティにより、保管場所から在庫品目の予算勘定が取得されます。

借方勘定を取得

この関数アクティビティにより、借方勘定が取得されます。

品目レベルの予算勘定を取得

この関数アクティビティにより、品目から在庫品目の予算勘定が取得されます。

組織レベルの予算勘定を取得

この関数アクティビティにより、組織から在庫品目の予算勘定が取得されます。

借方勘定ccidはNULLですか

これは、標準のワークフロー比較アクティビティです。ここでは、文書の「借方勘定」フィールドがNULLかどうかをチェックするために使用されます。関連項目: 『Oracle Workflow開発者ガイド』の比較アクティビティに関する項。

品目は予算管理下にありますか?

この関数アクティビティにより、予算引当会計が使用されているかどうかがチェックされます。

ショップ型WIPアカウント

外注加工製造オーダーの場合、この関数アクティビティにより、製造オーダーに関連付けられている生産資源費要素に基づいて借方勘定が取得されます。

PO経過勘定フレックスビルダのアップグレード

「発注勘定科目ジェネレータ」の場合、この関数アクティビティにより、勘定科目ジェネレータ内の経過勘定フレックスビルダー・ルールが複製されます。リリース10.7からのアップグレード時に生成された該当する関数がコールされます。

PO予算勘定フレックスビルダのアップグレード

「発注勘定科目ジェネレータ」の場合、この関数アクティビティにより、勘定科目ジェネレータ内の予算勘定フレックスビルダー・ルールが複製されます。リリース10.7からのアップグレード時に生成された該当する関数がコールされます。

PO借方勘定フレックスビルダのアップグレード

「発注勘定科目ジェネレータ」の場合、この関数アクティビティにより、勘定科目ジェネレータ内の借方勘定フレックスビルダー・ルールが複製されます。リリース10.7からのアップグレード時に生成された該当する関数がコールされます。

PO購買依頼経過勘定フレックスビルダのアップグレード

「PO購買依頼勘定科目ジェネレータ」の場合、この関数アクティビティにより、勘定科目ジェネレータ内の経過勘定フレックスビルダー・ルールが複製されます。リリース10.7からのアップグレード時に生成された該当する関数がコールされます。

PO購買依頼予算勘定フレックスビルダのアップグレード

「PO購買依頼勘定科目ジェネレータ」の場合、この関数アクティビティにより、勘定科目ジェネレータ内の予算勘定フレックスビルダー・ルールが複製されます。リリース10.7からのアップグレード時に生成された該当する関数がコールされます。

PO購買依頼借方勘定フレックスビルダのアップグレード

「PO購買依頼勘定科目ジェネレータ」の場合、この関数アクティビティにより、勘定科目ジェネレータ内の借方勘定フレックスビルダー・ルールが複製されます。リリース10.7からのアップグレード時に生成された該当する関数がコールされます。

PO購買依頼差異勘定フレックスビルダのアップグレード

「PO購買依頼勘定科目ジェネレータ」の場合、この関数アクティビティにより、勘定科目ジェネレータ内の差異勘定フレックスビルダー・ルールが複製されます。リリース10.7からのアップグレード時に生成された該当する関数がコールされます。

プロジェクト関連の発注ですか?

「発注勘定科目ジェネレータ」の場合、この関数アクティビティにより、発注品目がOracle Projectsでのプロジェクトに関するものかどうかがチェックされます。

プロジェクト関連の購買依頼ですか?

「PO購買依頼勘定科目ジェネレータ」の場合、この関数アクティビティにより、購買依頼品目がOracle Projectsでのプロジェクトに関するものかどうかがチェックされます。

PO差異勘定フレックスビルダのアップグレード

「発注勘定科目ジェネレータ」の場合、この関数アクティビティにより、勘定科目ジェネレータ内の差異勘定フレックスビルダー・ルールが複製されます。リリース10.7からのアップグレード時に生成された該当する関数がコールされます。

スケジュール・アカウント

外注加工ライン型製造オーダーの場合、この関数アクティビティにより、ライン型製造オーダーに関連付けられている生産資源費要素に基づいて借方勘定が取得されます。

WIPタイプ

製造現場品目の場合、この関数アクティビティにより、外注加工タイプが「製造オーダー」であるか「スケジュール」であるかがチェックされます。

組織から差異勘定

この関数アクティビティにより、組織から在庫品目と製造現場品目の差異勘定が取得されます。

作業項目の搬送先タイプ

この関数アクティビティにより、品目の搬送先タイプが「在庫」、「製造現場」または「費用」のいずれであるかがチェックされます。

エラー・メッセージの設定

この関数アクティビティは、ワークフローのプロセスでは使用されませんが、ワークフローのカスタマイズに役立てるために用意されています。この関数アクティビティを使用して、カスタマイズしたエラー・メッセージを作成できます。この関数アクティビティで使用する前に、メッセージをOracle Applicationsメッセージ・ディクショナリ内で定義する必要があります。

手順は、「Oracle Purchasing用勘定科目ジェネレータのカスタマイズ」の「「エラー・メッセージの設定」関数アクティビティを使用する手順」を参照してください。

「デフォルト経過勘定の生成」サブプロセスの概要

このプロセスのプロパティを表示するには、このプロセスをナビゲータ・ツリーで選択し、「編集」メニューから「プロパティ」を選択します。このプロセスの結果タイプは「フレックスフィールドの結果」で、プロセスの完了時に結果が「失敗」または「成功」となることを示します。これらの結果は、「標準フレックスフィールド・ワークフロー」項目タイプの「フレックスフィールドの結果」参照タイプの参照コードに対応します。

このプロセス・アクティビティは実行不可で、最上位レベル・プロセスとしては開始できませんが、上位レベル・プロセスによりコールされた場合にサブプロセスとしてのみ実行できます。

このサブプロセスはノード1で始まります。

ノード2では、品目の搬送先タイプが「在庫」、「製造現場」または「費用」のいずれであるかがチェックされます。

費用品目の場合、ノード8で最初に品目がプロジェクト関連かどうかがチェックされます。プロジェクト関連の場合、ノード11のサブプロセスを適切にカスタマイズしていれば、このサブプロセスによりプロジェクト関連の勘定が作成されます。

品目がプロジェクト関連でない場合は、ノード9で経過勘定が取得されます。在庫品目と製造現場品目の場合は、ノード3で組織から経過勘定が取得されます。関連項目: Oracle Purchasingでの勘定科目ジェネレータの使用方法の表。

ノード5および6は、標準のフレックスフィールド・ワークフロー・アクティビティです。関連項目: 『Oracle Applicationsフレックスフィールド・ガイド』の標準フレックスフィールド・ワークフローに関する項。

「デフォルト予算勘定の生成」サブプロセスの概要

このプロセスのプロパティを表示するには、このプロセスをナビゲータ・ツリーで選択し、「編集」メニューから「プロパティ」を選択します。このプロセスの結果タイプは「フレックスフィールドの結果」で、プロセスの完了時に結果が「失敗」または「成功」となることを示します。これらの結果は、「標準フレックスフィールド・ワークフロー」項目タイプの「フレックスフィールドの結果」参照タイプの参照コードに対応します。

このプロセス・アクティビティは実行不可で、最上位レベル・プロセスとしては開始できませんが、上位レベル・プロセスによりコールされた場合にサブプロセスとしてのみ実行できます。

このサブプロセスはノード1で始まります。

ノード2では、品目がプロジェクト関連かどうかがチェックされます。プロジェクト関連の場合、ノード3のサブプロセスを適切にカスタマイズしていれば、このサブプロセスによりプロジェクト関連の勘定が作成されます。

ノード6では、品目の搬送先タイプが「在庫」、「費用」または「製造現場」のいずれであるかがチェックされます。

予算引当を使用していても、勘定科目ジェネレータでは製造現場配分用の予算勘定は作成されないため、製造現場品目の場合はサブプロセスがノード7で終了します。

費用品目の場合、ノード10で借方勘定から予算勘定が取得されます。

在庫品目の場合、ノード8のサブプロセスにより在庫予算勘定が作成されます。関連項目: 「在庫予算勘定の作成」サブプロセスの概要。

ノード12および13は、標準のフレックスフィールド・ワークフロー・アクティビティです。関連項目: 『Oracle Applicationsフレックスフィールド・ガイド』の標準フレックスフィールド・ワークフローに関する項。

「デフォルト借方勘定の生成」サブプロセスの概要

このプロセスのプロパティを表示するには、このプロセスをナビゲータ・ツリーで選択し、「編集」メニューから「プロパティ」を選択します。このプロセスの結果タイプは「フレックスフィールドの結果」で、プロセスの完了時に結果が「失敗」または「成功」となることを示します。これらの結果は、「標準フレックスフィールド・ワークフロー」項目タイプの「フレックスフィールドの結果」参照タイプの参照コードに対応します。

このプロセス・アクティビティは実行不可で、最上位レベル・プロセスとしては開始できませんが、上位レベル・プロセスによりコールされた場合にサブプロセスとしてのみ実行できます。

このサブプロセスはノード1で始まります。

ノード2では、品目の搬送先タイプが「製造現場」、「在庫」または「費用」のいずれであるかがチェックされます。

製造現場品目の場合、ノード3で製造現場借方勘定が作成されます。関連項目: 「製造現場借方勘定の作成」サブプロセスの概要。在庫品目の場合、ノード5で在庫借方勘定が作成されます。関連項目: 「在庫借方勘定の作成」サブプロセスの概要。費用品目の場合、ノード9で費用借方勘定が作成されます。関連項目: 「費用借方勘定の作成」サブプロセスの概要。

ノード9で費用品目の借方勘定作成に成功した場合、ワークフローではコード組合せが即時に検証されません。かわりに、費用品目の文書に独自の借方勘定を入力できるため、ノード10では最初に全セグメントが入力されたかどうかがチェックされます。

• 全セグメントが入力済であれば、ノード12で「コード組合せIDを生成」関数属性を使用して完全なコード組合せ識別子（CCID）が生成されます。

• 未入力のセグメントがあると、ノード11で「値が入っているセグメントのみの検証」関数属性を使用して入力済セグメントのみが検証されます。

ノード6、10、11および12は、標準のフレックスフィールド・ワークフロー・アクティビティです。関連項目: 『Oracle Applicationsフレックスフィールド・ガイド』の標準フレックスフィールド・ワークフローに関する項。

「デフォルト差異勘定の生成」サブプロセスの概要

このプロセスのプロパティを表示するには、このプロセスをナビゲータ・ツリーで選択し、「編集」メニューから「プロパティ」を選択します。このプロセスの結果タイプは「フレックスフィールドの結果」で、プロセスの完了時に結果が「失敗」または「成功」となることを示します。これらの結果は、「標準フレックスフィールド・ワークフロー」項目タイプの「フレックスフィールドの結果」参照タイプの参照コードに対応します。

このプロセス・アクティビティは実行不可で、最上位レベル・プロセスとしては開始できませんが、上位レベル・プロセスによりコールされた場合にサブプロセスとしてのみ実行できます。

このサブプロセスはノード1で始まります。

ノード2では、搬送先タイプが「製造現場」、「在庫」または「費用」のいずれであるかがチェックされます。

製造現場品目または在庫品目の場合、ノード5で組織から差異勘定が取得されます。費用品目の場合は、ノード3で借方勘定が取得されます。関連項目: Oracle Purchasingでの勘定科目ジェネレータの使用方法の表。

ノード7は、標準フレックスフィールド・ワークフロー・アクティビティです。関連項目: 『Oracle Applicationsフレックスフィールド・ガイド』の標準フレックスフィールド・ワークフローに関する項。

「費用借方勘定の作成」サブプロセスの概要

このプロセスのプロパティを表示するには、このプロセスをナビゲータ・ツリーで選択し、「編集」メニューから「プロパティ」を選択します。このプロセスの結果タイプは「フレックスフィールドの結果」で、プロセスの完了時に結果が「失敗」または「成功」となることを示します。これらの結果は、「標準フレックスフィールド・ワークフロー」項目タイプの「フレックスフィールドの結果」参照タイプの参照コードに対応します。

このプロセス・アクティビティは実行不可で、最上位レベル・プロセスとしては開始できませんが、上位レベル・プロセスによりコールされた場合にサブプロセスとしてのみ実行できます。

このサブプロセスはノード1で始まります。

費用品目の場合、このサブプロセスでは最初にノード2で品目がプロジェクト関連かどうかがチェックされます。プロジェクト関連の場合、ノード3のサブプロセスを適切にカスタマイズしていれば、このサブプロセスによりプロジェクト関連の勘定が作成されます。

費用品目がプロジェクト関連でなければ、ノード5で費用借方勘定が取得されます。関連項目: Oracle Purchasingでの勘定科目ジェネレータの使用方法の表。

ノード6は、標準フレックスフィールド・ワークフロー・アクティビティです。関連項目: 『Oracle Applicationsフレックスフィールド・ガイド』の標準フレックスフィールド・ワークフローに関する項。

「在庫借方勘定の作成」サブプロセスの概要

このプロセスのプロパティを表示するには、このプロセスをナビゲータ・ツリーで選択し、「編集」メニューから「プロパティ」を選択します。このプロセスの結果タイプは「フレックスフィールドの結果」で、プロセスの完了時に結果が「失敗」または「成功」となることを示します。これらの結果は、「標準フレックスフィールド・ワークフロー」項目タイプの「フレックスフィールドの結果」参照タイプの参照コードに対応します。

このプロセス・アクティビティは実行不可で、最上位レベル・プロセスとしては開始できませんが、上位レベル・プロセスによりコールされた場合にサブプロセスとしてのみ実行できます。

このサブプロセスはノード1で始まります。

在庫品目の場合、このサブプロセスのノード2で、品目が費用品目であるか資産品目であるかに基づいて、適切な借方勘定が取得されます。関連項目: Oracle Purchasingでの勘定科目ジェネレータの使用方法の表。

ノード4は、標準フレックスフィールド・ワークフロー・アクティビティです。関連項目: 『Oracle Applicationsフレックスフィールド・ガイド』の標準フレックスフィールド・ワークフローに関する項。

「製造現場借方勘定の作成」サブプロセスの概要

このプロセスのプロパティを表示するには、このプロセスをナビゲータ・ツリーで選択し、「編集」メニューから「プロパティ」を選択します。このプロセスの結果タイプは「フレックスフィールドの結果」で、プロセスの完了時に結果が「失敗」または「成功」となることを示します。これらの結果は、「標準フレックスフィールド・ワークフロー」項目タイプの「フレックスフィールドの結果」参照タイプの参照コードに対応します。

このプロセス・アクティビティは実行不可で、最上位レベル・プロセスとしては開始できませんが、上位レベル・プロセスによりコールされた場合にサブプロセスとしてのみ実行できます。

このサブプロセスはノード1で始まります。

製造現場品目の場合、このサブプロセスのノード2では、品目が外注加工のショップ型製造オーダー関連かライン型製造オーダー関連かがチェックされます。ショップ型製造オーダーの場合、ノード3でショップ型製造オーダーに関連付けられている生産資源費要素に基づいて借方勘定が取得されます。ライン型製造オーダーの場合、ノード7でライン型製造オーダーに関連付けられている生産資源費要素に基づいて借方勘定が取得されます。関連項目: Oracle Purchasingでの勘定科目ジェネレータの使用方法の表。

ノード5は、標準フレックスフィールド・ワークフロー・アクティビティです。関連項目: 『Oracle Applicationsフレックスフィールド・ガイド』の標準フレックスフィールド・ワークフローに関する項。

「在庫予算勘定の作成」サブプロセスの概要

このプロセスのプロパティを表示するには、このプロセスをナビゲータ・ツリーで選択し、「編集」メニューから「プロパティ」を選択します。このプロセスの結果タイプは「フレックスフィールドの結果」で、プロセスの完了時に結果が「失敗」または「成功」となることを示します。これらの結果は、「標準フレックスフィールド・ワークフロー」項目タイプの「フレックスフィールドの結果」参照タイプの参照コードに対応します。

このプロセス・アクティビティは実行不可で、最上位レベル・プロセスとしては開始できませんが、上位レベル・プロセスによりコールされた場合にサブプロセスとしてのみ実行できます。

このサブプロセスはノード1で始まります。

在庫品目の場合、このサブプロセスのノード2で最初に保管場所から予算勘定が取得されます。保管場所で勘定が指定されていなければ、ノード4で品目の予算勘定が検索されます。そこでも勘定が指定されていなければ、ノード5で組織の予算勘定が検索されます。そこでも勘定が指定されていなければ、ノード6で予算勘定の借方勘定が取得されます。関連項目: Oracle Purchasingでの勘定科目ジェネレータの使用方法の表。

「プロジェクト勘定の作成」サブプロセスの概要

「プロジェクト勘定の作成」サブプロセスのプロパティを表示するには、このプロセスをナビゲータ・ツリーで選択し、「編集」メニューから「プロパティ」を選択します。各「プロジェクト勘定の作成」サブプロセスの結果タイプは「フレックスフィールドの結果」で、プロセスの完了時に結果が「失敗」または「成功」となることを示します。これらの結果は、「標準フレックスフィールド・ワークフロー」項目タイプの「フレックスフィールドの結果」参照タイプの参照コードに対応します。

これらのサブプロセス・アクティビティは実行不可で、最上位レベル・プロセスとしては開始できず、上位レベル・プロセスによりコールされた場合にサブプロセスとしてのみ実行できることを示します。

「プロジェクト勘定の作成」サブプロセスとして、作成対象となる勘定ごとに次の4つが用意されています。

• 費用プロジェクト経過勘定の作成

• 費用プロジェクト予算勘定の作成

• 費用プロジェクト借方勘定の作成

• 費用プロジェクト差異勘定の作成

「プロジェクト勘定の作成」サブプロセスは、Oracle Projectsをインストール済の場合に勘定科目作成プロセスのカスタマイズに使用可能なダミー・プロセスです。このプロセスを使用するには、独自の勘定科目作成ルールをワークフロー・プロセス定義の形式でプロセスに提供します。

後述のように、「プロジェクト関連の購買依頼ですか?」関数アクティビティではデフォルトで常に値「FALSE」が戻されます。これは、「プロジェクト関連科目の作成」プロセスがダミー・プロセスであることを意味します。「プロジェクト関連の購買依頼ですか?」関数アクティビティを、文書のプロジェクトIDをチェックする独自の関数アクティビティに置き換えるまでは使用されません。

「プロジェクト関連の発注ですか?」のかわりに標準ワークフロー関数アクティビティ「数値の比較」を使用できます。「数値の比較」を使用すると、文書のプロジェクトIDを定義した値と比較したり、プロジェクトIDの有無をチェックできます。プロジェクトIDがなければ、「数値の比較」は「経費勘定」アクティビティに遷移し、デフォルト経費勘定が作成されます。プロジェクトIDがある場合、「数値の比較」は「プロジェクト関連科目の作成」プロセスに遷移し、勘定が作成されます。関連項目: 『Oracle Workflow開発者ガイド』の比較アクティビティに関する項。

品目をプロジェクト勘定に請求する場合は、次の操作を実行する必要があります。

• 「プロジェクト関連の購買依頼ですか?」（「プロジェクト関連の発注ですか?」）を、文書にプロジェクトIDがある場合に「プロジェクト勘定の作成」サブプロセスに分岐する独自の関数アクティビティに置き換えます。

• 該当する「プロジェクト勘定の作成」サブプロセスをカスタマイズします。前述の例では、「費用プロジェクト借方勘定の作成」サブプロセスをカスタマイズすることになります。すべての勘定（経過、予算、借方および差異）にプロジェクト関連勘定を使用する場合は、4つの「プロジェクト勘定の作成」サブプロセスをすべてカスタマイズします。

Oracle PurchasingをOracle Projectsと統合する際の勘定科目ジェネレータの使用方法の詳細は、『Oracle Projectsユーザーズ・ガイド』のOracle Projectsでの勘定科目ジェネレータの使用に関する項を参照してください。

「差異勘定の借方勘定を取得」サブプロセスの概要

このプロセスのプロパティを表示するには、このプロセスをナビゲータ・ツリーで選択し、「編集」メニューから「プロパティ」を選択します。このプロセスの結果タイプは「フレックスフィールドの結果」で、プロセスの完了時に結果が「失敗」または「成功」となることを示します。これらの結果は、「標準フレックスフィールド・ワークフロー」項目タイプの「フレックスフィールドの結果」参照タイプの参照コードに対応します。

このプロセス・アクティビティは実行不可で、最上位レベル・プロセスとしては開始できませんが、上位レベル・プロセスによりコールされた場合にサブプロセスとしてのみ実行できます。

このサブプロセスはノード1で始まります。

費用品目の場合、このサブプロセスでは最初にノード2で品目がプロジェクト関連かどうかがチェックされます。プロジェクト関連の場合、このサブプロセス適切にカスタマイズしていれば、ノード3でサブプロセスによりプロジェクト関連の勘定が作成されます。

品目がプロジェクト関連でなければ、ノード5で差異勘定の作成に使用する借方勘定が取得されます。

ノード7は、標準フレックスフィールド・ワークフロー・アクティビティです。関連項目: 『Oracle Applicationsフレックスフィールド・ガイド』の標準フレックスフィールド・ワークフローに関する項。

「組織から差異勘定を取得」サブプロセスの概要

このプロセスのプロパティを表示するには、このプロセスをナビゲータ・ツリーで選択し、「編集」メニューから「プロパティ」を選択します。このプロセスの結果タイプは「フレックスフィールドの結果」で、プロセスの完了時に結果が「失敗」または「成功」となることを示します。これらの結果は、「標準フレックスフィールド・ワークフロー」項目タイプの「フレックスフィールドの結果」参照タイプの参照コードに対応します。

このプロセス・アクティビティは実行不可で、最上位レベル・プロセスとしては開始できませんが、上位レベル・プロセスによりコールされた場合にサブプロセスとしてのみ実行できます。

このサブプロセスはノード1で始まります。

在庫品目と製造現場品目の場合、ノード2で組織から差異勘定が取得されます。関連項目: Oracle Purchasingでの勘定科目ジェネレータの使用方法の表。

ノード3は、標準フレックスフィールド・ワークフロー・アクティビティです。関連項目: 『Oracle Applicationsフレックスフィールド・ガイド』の標準フレックスフィールド・ワークフローに関する項。

「フレックスビルダ・ルールを使った勘定科目の生成」プロセスの概要

このプロセスのプロパティを表示するには、このプロセスをナビゲータ・ツリーで選択し、「編集」メニューから「プロパティ」を選択します。このプロセスの結果タイプは「フレックスフィールドの結果」で、プロセスの完了時に結果が「失敗」または「成功」となることを示します。これらの結果は、「標準フレックスフィールド・ワークフロー」項目タイプの「フレックスフィールドの結果」参照タイプの参照コードに対応します。

このプロセス・アクティビティは実行可能でもあります。これは、ワークフロー・エンジンのCreateProcessおよびStartProcess APIのコールによってトップ・レベル・プロセスとして実行できることを示します。

以前のリリースで、勘定科目組合せを生成するようにフレックスビルダーをカスタマイズした場合は、「フレックスビルダ・ルールを使った勘定科目の生成」プロセスを使用してフレックスビルダーの設定を自動的に複製できます。事前定義済のフレックスビルダー・ルールを変更したり、勘定科目ジェネレータをカスタマイズする必要はありません。この最上位レベル・プロセスは、次のプロセスで構成されています。

• （ノード3）「フレックスビルダ・ルールを使った借方勘定の生成」により、勘定科目ジェネレータ内で借方勘定フレックスビルダー・ルールが複製されます。

• （ノード8）「フレックスビルダ・ルールを使った予算勘定の生成」により、勘定科目ジェネレータ内で予算勘定フレックスビルダー・ルールが複製されます（ノード7のアクティビティにより、品目が予算管理下にあることが検出された場合）。

• （ノード11）「フレックスビルダ・ルールを使った経過勘定の生成」により、勘定科目ジェネレータ内で経過勘定フレックスビルダー・ルールが複製されます。

• （ノード13）「フレックスビルダ・ルールを使った差異勘定の生成」により、勘定科目ジェネレータ内で差異勘定フレックスビルダー・ルールが複製されます。

「フレックスビルダ・ルールを使った勘定科目の生成」プロセスでは、勘定科目を生成するために、リリース10.7からのアップグレード時に生成された該当する関数がコールされます。

リリース10からアップグレードする場合は、『Oracle Applicationsのアップグレード』の「フレックスビルダー」、ガイドラインに関する項を参照してください。

勘定科目ジェネレータとワークフロー・モニターの併用

テスト中または問題の診断中にワークフロー・モニターを使用して勘定科目生成結果を表示する場合は、「勘定科目ジェネレータ: デバッグ・モードで実行」プロファイル・オプションを「Yes」に設定します。テスト終了後は、パフォーマンスを維持するために、このオプションを必ず「No」に設定してください。「システム管理者」職責でアクセス可能な「廃止ワークフロー・ランタイム・データのパージ」プロセスを使用して、ランタイム・データを定期的にパージします。

ワークフローの進行中に文書をモニターするには、モニター対象となる文書とそのモニター先プロセスの両方に固有の項目キーをワークフロー・モニターに入力する必要があります。

ワークフロー・モニターの使用方法は、『Oracle Workflowユーザーズ・ガイド』のワークフロー・プロセスのモニタリングに関する項を参照してください。

勘定科目ジェネレータ・ワークフローの項目キーを判別する手順は、次のとおりです。

1. Oracle Purchasingで、モニターする文書をオープンし、「ヘルプ」メニューから「ツール」>「検査」を選択します。

   「ツール」>「検査」は、パスワードで管理されている場合があります。アクセスできない場合は、システム管理者に確認してください。

2. 「ブロック」フィールドの右にある下矢印のボックスを選択します。

3. 表示される値リストから「PARAMETER」を選択し、「OK」を選択します。

4. 「フィールド」フィールドにcharge_acc_wf_itemkeyと入力します。

   「値」フィールドに項目キーが表示されます。ワークフロー・モニターに項目キーの入力を求めるプロンプトが表示された場合は、この項目キーを使用します。

購買依頼承認ワークフロー

「通知要約」ウィンドウで購買依頼を承認のために発行するか処理を実行すると、Oracle PurchasingではバックグラウンドでOracle Workflowテクノロジを使用して承認プロセスが処理されます。Oracle Workflowでは、「文書承認とセキュリティの設定」の設定ステップに従って定義した承認管理と承認階層を使用して、文書が承認へと導かれます。Oracle Workflow Builderを使用すると、承認プロセスを変更できます。

購買依頼承認ワークフローは、Oracle Workflow Builderでダイアグラムとして参照可能なプロセスで構成されており、一部のオブジェクトとプロパティは変更可能です。各ワークフロー・プロセスは、個別の関数アクティビティで構成されています。

Oracle Purchasingでは、購買依頼の承認ワークフローは次の時点で開始されます。

• Oracle Purchasingの「承認文書」ウィンドウで「承認のために発行」を選択（および「OK」を選択）するか、Oracle iProcurementで購買依頼を承認のために発行した時点。

• 「通知要約」ウィンドウで、承認のために未発行の文書を発行するように促す催促に応答した時点。

• 「購買依頼インポート」の実行時。購買依頼が未完了または事前承認済の場合は、「購買依頼インポート」により購買依頼の承認ワークフローが起動され、特に指定しないかぎり購買依頼が承認されます。

発注承認ワークフローの詳細は、「発注承認ワークフロー」を参照してください。

購買依頼の承認ワークフローのカスタマイズ

ワークフローをカスタマイズするには、Oracle Workflow Builderを使用します。ワークフローをカスタマイズした場合、そのワークフローの影響を受けるのは、カスタマイズ後に承認のために発行される文書のみです。

Oracle Workflow Builderを使用して、組織内の文書タイプごとに一意の承認ワークフローを作成することもできます。「文書タイプ」ウィンドウで、特定のワークフローを特定の文書タイプに関連付けます。関連項目: 文書タイプの定義。

ワークフロー・モニターを使用すると、ワークフロー・プロセス内の特定の文書の位置をたどることができます。関連項目: 『Oracle Workflowユーザーズ・ガイド』のワークフロー・プロセスのモニタリングに関する項。

Oracle Workflow Builderでワークフローを表示する手順は、次のとおりです。

1. 「ファイル」メニューから「オープン」を選択して、データベースに接続します。

   関連項目: 『Oracle Workflow開発者ガイド』の項目タイプのオープンと保存に関する項

   購買依頼の承認ワークフローの表示名は「購買依頼の承認」です。ワークフロー定義ファイル名はpoxwfrqa.wftです。

   

2. データ・ソースを拡張し、そのデータ・ソース内で「購買依頼の承認」項目タイプのブランチを拡張します。

3. 「購買依頼の承認」ブランチ内の「プロセス」ブランチを拡張し、プロセス・アクティビティをダブルクリックしてダイアグラムを表示します。

新規カスタム処理の作成

Oracle Purchasingに用意されているデフォルトの購買依頼の承認ワークフローを変更する方法と、それをコピーして新規ワークフローを作成する方法があります。「文書タイプ」ウィンドウを使用すると、特定の文書タイプまたは営業単位用にカスタムの購買依頼の承認ワークフロー起動処理を選択できます。

文書や営業単位ごとに異なるワークフローを作成する場合は、項目タイプをコピーして名称変更するのではなく（購買依頼の承認1など）、「ワークフロー起動処理」をコピーして名称変更し、独自のカスタム・サブプロセスをコールするように変更することをお薦めします。全営業単位が同じ項目タイプを指し、その項目タイプに必要なデフォルトの項目属性と他のアクティビティを使用するようになりますが、営業単位の1つもカスタム起動処理を使用することになります。

重要: 新しい内部名を指定して新規ワークフロー・プロセスを作成すると、将来のアップグレードの実装に影響します。関連項目: アップグレードのサポート。

必要な変更

購買依頼の承認ワークフローに必須の変更はありません。ただし、この項ではOracle Purchasingの設定を完了し、ワークフロー・オプションで説明したOracle Workflow設定ステップを実行していることを前提としています。

サポートされるカスタマイズとサポートされないカスタマイズ

この項では、購買依頼の承認ワークフローについて、変更可能な内容と変更不可の内容を説明します。変更可能な内容については、カスタマイズする際に注意を必要とする重要なガイドラインについても説明します。

ワークフローのカスタマイズ方法に関する重要情報は、『Oracle Workflow開発者ガイド』を参照してください。

カスタマイズの参照情報は、「「購買依頼の承認」項目タイプ」以降の各項を参照してください。各項では、購買依頼の承認ワークフローのメイン・プロセスのコンポーネントについて説明しています。まだ参照していない場合は、「カスタマイズのガイドライン」も参照してください。

重要: 以降の各項で、特定のワークフロー・オブジェクトがカスタマイズ可能オブジェクトのリストに記載されていない場合は、アクセス・レベルに関係なく変更しないでください。

属性

変更できるのは次の属性のみで、デフォルト値を変更します。

• PO自動作成をバックグラウンドへ送付

デフォルト値が「Y」（Yes）の場合、自動文書作成はバックグラウンド・モードに送られますが、「N」（No）に変更するとオンライン・モードで操作できます。関連項目: ワークフロー・オプションの選択。

プロセス

プロセスを変更する場合は、データベース内のデータの整合性を維持するために基本的なフローをそのまま保つことが重要です。たとえば、「購買依頼を検証」サブプロセスの「文書は完了していますか?」関数アクティビティを削除またはバイパスしないでください。この関数アクティビティを削除またはバイパスすると、データベース表に対する不完全データの挿入が許可される可能性があります。ただし、表へのデータ挿入を許可する前に、付加的なチェック（プロセスまたは関数アクティビティ）を追加することはできます。

プロセスを変更するには、そのフローの一部を置き換える方法と、新しい関数アクティビティを追加する方法があります。どちらの場合も、次のことに注意してください。

• デフォルト・プロセスのデフォルト関数アクティビティによって設定される属性は、デフォルト関数アクティビティを独自のものに置き換えた場合も設定される必要があります。つまり、そのプロセス内の関数アクティビティがSetItemAttr文を使用している場合、その関数アクティビティは後で他の関数アクティビティに使用される属性を設定します。したがって、新しい関数アクティビティも同じ属性を設定する必要があります。また、 SetItemUserKey文およびSetItemOwner文があれば、それも保存する必要があります。（カスタマイズの内容によっては、GetItemAttr文も保存してください。）

• デフォルト・プロセスが保守しているデータベースの状態は、カスタマイズしたプロセスでも保守する必要があります。つまり、カスタマイズしたプロセスの関数アクティビティでUpdate文またはInsert Into文を使用する場合、その関数アクティビティは、データベースの行を更新または挿入します。したがって、新規の関数アクティビティは、データベースを同じ状態に保守する必要があります。

  SetItemAttr文、GetItemAttr文、SetItemUserKey文、SetItemOwner文、Insert Into文またはUpdate文を使用するワークフロー関数アクティビティのリストを取得するには、PL/SQLスクリプトpowfcustを実行します。このスクリプトの実行手順は、「カスタマイズのガイドライン」を参照してください。

後述のプロセスは、ビジネス・プロセスのニーズに応じて変更できます。ただし、カスタマイズ後は、設定されていた属性と、デフォルト・プロセスによって保守されていたデータベースの状態は、カスタマイズ後のプロセスでも設定または保守する必要があります。

• 文書の印刷プロセス

次の各プロセスには独自の関数アクティビティを追加できますが、デフォルトの関数アクティビティは削除できません。

• 購買依頼承認

• 購買依頼の否認

• 開始時に予約

• 承認前に予約

• 購買依頼を送信者に差戻す

• 承認権限を検証

• 承認処理に対する承認権限の検証

• 承認処理および転送処理に対する承認権限の検証

• 購買依頼を検証

• 承認リスト経路

• 主要購買依頼承認

• 承認者に通知

• 承認処理の応答

• 承認および転送処理の応答

• 転送処理の応答

• 否認処理の応答

• 承認前に予約

• 購買依頼承認プロセスの開始

通知

すべての通知は、個別のビジネス・ニーズにあわせて変更できます。ただし、通知に返信コードが含まれている場合は、カスタマイズした通知の「結果タイプ」がワークフロー・ダイアグラムでの遷移と一致していることを確認してください。関連項目: 『Oracle Workflow開発者ガイド』の通知アクティビティの作成に関する項。関連項目: 『Oracle Workflow開発者ガイド』のメッセージ結果に関する項。関連項目: 『Oracle Workflow開発者ガイド』のメッセージの作成に関する項。

関数アクティビティ

購買依頼の承認ワークフローの関数アクティビティは変更できません。

ただし、一部の関数アクティビティは、独自の関数アクティビティに置き換えることができます。関数アクティビティを置き換える場合は、それを含んでいるプロセスを変更します。関連項目: 前述の「プロセス」の「購買依頼の承認」プロセスのカスタマイズのガイドライン。

プロセスのデフォルト関数アクティビティを独自作成した関数アクティビティに置き換える場合は、次の点に注意する必要があります。

• 新しい関数アクティビティの結果タイプは、デフォルト・アクティビティの結果タイプと一致する必要があります。つまり、Oracle Workflow Builderにおける関数アクティビティの「結果タイプ」は、その関数アクティビティの対応するPL/SQLプロシージャで指定する結果タイプと一致する必要があります（「Yes/No」結果タイプなど）。また、関数アクティビティおよび対応するPL/SQLプロシージャに2つの結果（「Yes」と「No」など）がある場合は、ワークフロー・ダイアグラム内に2つの対応する遷移が（「Yes」に1つと「No」に1つ）存在することを確認してください。プロセスの結果タイプと遷移を変更する場合は、特別な遷移やチェックを削除またはバイパスしないように注意する必要があります。

• 前述の「プロセス」と同様に、デフォルト関数アクティビティにより設定されていた属性は、カスタマイズした関数アクティビティでも設定する必要があります。

• 前述の「プロセス」と同様に、デフォルト関数アクティビティにより維持されていたデータベース・ステータス性は、カスタマイズした関数アクティビティでも設定する必要があります。

メッセージ

すべてのメッセージは、個々のビジネス・ニーズにあわせて変更できます。

参照タイプ

すべての参照タイプは、個々のビジネス・ニーズに合せて変更できます。

注意: 参照タイプを変更する場合は、その参照タイプを使用するすべてのアクティビティを変更対象とみなしてください。たとえば、参照タイプを「Yes/No」から他のタイプに変更すると、その参照タイプを使用するアクティビティについても、「結果タイプ」を「Yes/No」から新規作成した参照タイプに変更する必要があります。関連項目: 参照タイプ。

「購買依頼の承認」ワークフロー項目タイプ

「購買依頼承認」プロセスには、「購買依頼の承認」という項目タイプが関連付けられています。この項目タイプにより、使用可能な購買依頼承認ワークフロー・プロセスがすべて識別されます。「購買依頼の承認」に関連付けられているワークフロー・プロセスは、次のとおりです。

• 主要購買依頼承認

• 購買依頼承認プロセスの開始

• 購買依頼を検証

• 開始時に予約

• 承認権限を検証

• 承認リスト経路

• 購買依頼の否認

• 購買依頼を送信者に差戻す

• 承認者に通知

• 承認処理の応答

• 承認および転送処理の応答

• 転送処理の応答

• 否認処理の応答

• 承認前に予約

• 購買依頼承認

• 文書の印刷プロセス

• 承認処理に対する承認権限の検証

• 承認処理および転送処理に対する承認権限の検証

「PO購買依頼の承認」項目タイプには、多数の属性も関連付けられています。これらの属性は、Oracle Purchasingアプリケーション表内の情報を参照します。各属性は、関数アクティビティおよびプロセス全体の通知アクティビティによって使用され、保守されます。

「購買依頼の承認」ワークフロー項目タイプの属性

「主要購買依頼承認」プロセスの概要

「主要購買依頼承認」プロセスのプロパティを表示するには、このプロセスをナビゲータ・ツリーで選択し、「編集」メニューから「プロパティ」を選択します。「主要購買依頼承認」プロセスの結果タイプは「発注主要購買依頼承認プロセスの結果」で、プロセスの完了時に結果が「承認済」、「無効な処理」、「使用可能な承認者がいない」または「否認済」となることを示します。これらの結果は、「発注標準」項目タイプの「発注主要購買依頼承認プロセスの結果」参照タイプの参照コードに対応します。

このプロセス・アクティビティは実行可能でもあります。これは、ワークフロー・エンジンのCreateProcessおよびStartProcess APIのコールによってトップ・レベル・プロセスとして実行できることを示します。

主要購買依頼承認ワークフローは、Oracle PurchasingまたはOracle iProcurementで購買依頼を発行すると開始されます。このワークフローでは、Oracle iProcurementで作成された購買依頼とOracle Purchasingで作成された購買依頼の両方が処理されます。

プロセス・ダイアグラムの最初の部分（ノード16まで）は、次のとおりです。

プロセス・ダイアグラムの後半部分（ノード16以降）は、次のとおりです。

ノード2では、すべての開始値が設定され、購買依頼ステータスが「処理中」に設定され、使用された承認モードが取得され、購買依頼属性が取得されます。

ノード3で購買依頼が検証を通過した場合、引当を使用していれば、ノード5でOracle iProcurement購買依頼の承認プロセスの開始時に予算が予約されます。

ノード6では、Oracle iProcurementで依頼者が承認リストを作成したのか変更したのかがチェックされます。どちらでもない場合、または購買依頼がOracle Purchasingで作成された場合は、ノード7でOracle Purchasingでの承認階層設定に基づいてデフォルト承認リストが作成されます。

ノード7で（システム障害や承認階層の問題などが原因で）デフォルト承認リストを作成できない場合、購買依頼はノード8で依頼者に差し戻されます。

ノード10では文書タイプに対して「所有者は承認可能」が有効化されているかどうかがチェックされ、ノード15では所有者の承認権限が検証されます。所有者が文書を承認できなければ、ノード11で承認リストに従って購買依頼が導かれます。

承認者が「否認」で応答すると、ノード12で購買依頼が否認され、ノード13で依頼者に否認通知が送信されます。購買依頼に問題があれば、ノード8で差し戻されます。

承認者が「承認」で応答すると、ノード18以降でワークフローによる文書の承認が開始されます。ノード18では、引当会計が使用されており、文書の予算がまだ予約されていなければ、ノード20で文書が承認される前に文書に対して予算が予約されます。

購買依頼が転送される場合は、ノード19で承認リストが再作成され、その転送先が追加されます。次に、ノード11でその承認者に購買依頼が転送されます。

ノード10および15では依頼者が文書を承認できることが確認され、ノード16で購買依頼ステータスが「事前承認済」に設定されます。次に、ノード17で他の承認者が示されなければ、ワークフローにより文書が承認されます。引当が使用されていれば、ノード18で予算が予約済であることが確認され、ノード20で文書が承認されてステータスが「承認済」に設定されます。

以降のノードは次のとおりです。

• Oracle iProcurementで情報テンプレートが使用された場合は、ノード23でOracle iProcurement情報テンプレートが添付に変換されます。

• ノード24では、購買依頼が承認されたことを示す通知が文書所有者に送信されます。

• 購買依頼の発行時に「印刷」が選択されていれば、ノード25で文書が印刷されます。

• ノード26では、「PO自動作成をバックグラウンドへ送付」項目属性が検索されます。この属性により、特に自動文書作成の処理モードが「バックグラウンド」（項目属性が「Y」に設定されている場合）または「オンライン」（項目属性が「N」に設定されている場合）に設定されます。このモードの設定は、システム・パフォーマンスに影響します。「バックグラウンド」および「オンライン」モードの定義は、「Oracle Purchasingのプロファイル・オプションとプロファイル・オプション・カテゴリ」を参照してください。

• ノード28では、自動的に発注文書の作成ワークフローが開始されます。Oracle Purchasing設定で許可していれば、このワークフローにより承認済購買依頼明細から発注とリリースが作成されます。関連項目: ワークフロー・オプションの選択。

「主要購買依頼承認」プロセスのアクティビティ

この項では、「主要購買依頼承認」プロセスの各アクティビティについて説明します。

購買依頼承認プロセスの開始（ノード2）

関連項目: 購買依頼承認プロセスの開始

購買依頼を検証（ノード3）

関連項目: 購買依頼を検証

開始時に予約（ノード5）

関連項目: 開始時に予約

承認リストが存在しますか?（ノード6）

このアクティビティでは、Oracle iProcurementで依頼者が承認リストを作成したのか変更したのかがチェックされます。

デフォルト承認リストの作成（ノード7）

Oracle iProcurementで依頼者が承認リストを作成または変更していない場合、または購買依頼がOracle Purchasingで発行された場合、このアクティビティではOracle Purchasingでの承認階層設定に基づいて承認リストが作成されます。

所有者は承認が可能か?（ノード10）

この関数アクティビティでは、「文書タイプ」ウィンドウで特定の文書タイプに対して「所有者は承認可能」が有効化されているかどうかがチェックされます。関連項目: 文書タイプの定義。所有者が承認可能な場合、「承認権限を検証」サブプロセスにより所有者の承認権限が検証されます。所有者が承認可能でない場合は、「承認リスト経路」サブプロセスが開始されます。

承認権限を検証（ノード15）

関連項目: 承認権限を検証

ステータスを「事前承認済」に設定（ノード16）

依頼者が文書の承認権限を付与されている場合、この関数アクティビティにより購買依頼のステータスが「事前承認済」に設定されます。ステータスは、「購買依頼を承認」サブプロセスまたは「承認前に予約」サブプロセスにより明示的に「承認済」に設定されるまで、「事前承認済」に設定されています。

このアクティビティでは文書ステータスのみが更新され、処理履歴は更新されません。「処理履歴」ウィンドウは、後から別のアクティビティである「処理履歴の更新」により更新されます。

承認リストは空白ですか?（ノード17）

このアクティビティでは、それ以上承認者がいないことが確認されます。承認者がいなければ、ワークフローにより購買依頼の承認が開始されます。承認者がいれば、ワークフローにより文書が承認へと導かれます。

承認リスト経路（ノード11）

関連項目: 承認リスト経路

購買依頼の否認（ノード12）

関連項目: 購買依頼の否認

購買依頼否認済（ノード13）

このアクティビティでは、購買依頼が否認されたことを示す通知が依頼者に送信されます。

購買依頼を送信者に差戻す（ノード8）

関連項目: 購買依頼を送信者に差戻す

送付処理後の承認リストの再作成（ノード19）

購買依頼が転送される場合は、このアクティビティにより承認リストが再作成され、その転送先が追加されます。

Oracle iProcurementの例

• 承認者A

• 承認者B

• 承認者C

Oracle iProcurementで依頼者が承認者XおよびYを追加するとします。

• 承認者A

• 承認者B

• 承認者C

• 承認者X

• 承認者Y

ただし、承認者Cは、階層内の別のブランチに属している承認者Dに文書を転送するとします。

• 承認者D

• 承認者E

• 承認者F

承認者Dに最終承認権限がない場合、承認経路は次のようになります。

• 承認者A

• 承認者B

• 承認者C

• 承認者X

• 承認者Y

• 承認者D

• 承認者E

• 承認者F

承認前に予約（ノード18）

関連項目: 承認前に予約

購買依頼を承認（ノード20）

関連項目: 購買依頼を承認

Webから購買依頼が作成されましたか?（ノード22）

このアクティビティでは、購買依頼がOracle iProcurementを介して作成されたかどうかがチェックされます。

情報テンプレート添付の作成（ノード23）

このアクティビティでは、Oracle iProcurement情報テンプレート（使用されている場合）が添付に変換されます。Oracle Purchasingの「情報テンプレートの定義」ウィンドウを使用すると、これらのテンプレートをOracle iProcurement用に定義できます。たとえば、Oracle iProcurementで名刺の発注に使用するテンプレートを作成できます。名刺情報の収集に使用するテンプレートは、このアクティビティによりOracle Purchasingでの添付に変換されます。

注意: Oracle iProcurementの情報テンプレートは、Oracle Purchasingの購買依頼テンプレートとは異なります。関連項目: 『Oracle iProcurement Implementation Manual』。

購買依頼承認済（ノード24）

この関数アクティビティでは、購買依頼が承認されたことを示す通知が該当するユーザーに送信されます。

この通知のメッセージでは、「文書タイプ」項目属性を使用して2つのPL/SQL関数がコールされます。一方により文書内の明細がすべて取得されて通知に表示され、他方により文書の処理履歴が取得されて通知に表示されます。

文書の印刷プロセス（ノード25）

関連項目: 文書の印刷プロセス

発注自動作成モードの取得（ノード26）

「ワークフローの承認モードを取得」関数アクティビティでは、「PO: ワークフロー処理モード」プロファイル・オプションの設定に基づいてOracle Purchasingで承認ワークフロー全体の処理モードが設定されますが、この関数アクティビティでは「PO自動作成をバックグラウンドへ送付」項目属性が検索されます。これにより、自動発注作成用の処理モードを個別に変更できます。バックグラウンド・モードでは、この文書の承認プロセスがバックグラウンドで完了する間に、次の購買アクティビティに進むことができます。

バックグラウンド・プロセスを待機（ノード27）

「PO自動作成をバックグラウンドへ送付」項目属性が「Yes」に設定されている場合、この関数アクティビティはワークフロー・バックグラウンド・エンジンによりこの文書がワークフローでの処理のために選択されるまで待機します。このアクティビティでは、この文書の承認プロセスがバックグラウンドで完了する間に、次の購買アクティビティに進むことができます。

発注ワークフロー作成を起動（ノード28）

承認済購買依頼明細の自動承認を許可している場合は、購買依頼が承認された後、「主要購買依頼承認」プロセスにより発注の自動作成ワークフローが起動されます。承認済購買依頼明細の自動承認が許可されるのは、「自動作成は許可されていますか?」項目属性が「Y」（Yes）に設定されている場合です。（デフォルトでは、この項目属性は「Y」に設定されます。）

「購買依頼承認プロセスの開始」の概要

「購買依頼承認プロセスの開始」のプロパティを表示するには、このプロセスをナビゲータ・ツリーで選択し、「編集」メニューから「プロパティ」を選択します。このサブプロセスの結果タイプは「発注アクティビティ実行」で、サブプロセスの完了時に結果が「アクティビティが実行されました」となることを示します。この結果は、「発注標準」項目タイプの「発注アクティビティ実行」参照タイプの参照コードに対応します。

このプロセス・アクティビティは実行不可で、最上位レベル・プロセスとしては開始できず、他の上位レベル・プロセスによりコールされた場合にのみ実行できることを示します。

このサブプロセスはノード1で始まります。

ノード2では、ワークフローに送信された文書の前のバージョンが未完了または否認済であれば、この文書に関する前の通知が削除されます。ノード3では、開始値が設定されます。ノード4では、購買依頼ステータスが「処理中」に設定されます。

ノード5では、Oracle iProcurementで作成された承認リストが検索されます。（この場合、ノード5では承認リストが検索されてOracle Purchasingの承認リスト表が更新されます。「主要購買依頼承認」プロセスの「承認リストが存在しますか?」アクティビティでは、単に承認リストが再チェックされて主要プロセスでの分岐方法が決定されます。）

ノード6では、購買依頼承認プロセスが「PO: ワークフロー処理モード」プロファイル・オプションに従って「オンライン」と「バックグラウンド」のどちらのパフォーマンス・モードで実行するように設定されているかが判別され、「バックグラウンド」に設定されている場合は、ノード7でバックグラウンド・エンジンが開始されるまで待機します。ノード8では、購買依頼属性（購買依頼情報と内部ワークフロー属性）が取得されます。

「購買依頼承認プロセスの開始」のアクティビティ

ここでは、「購買依頼承認プロセスの開始」プロセスの各アクティビティについて、アクティビティの表示名順に説明します。

この文書の通知をすべて削除（ノード2）

この関数アクティビティでは、前にワークフローに発行済で、エラーまたは否認などの処理が原因で完了しなかった購買依頼に関して、前の通知が削除されます。

ワークフローの開始値を設定（ノード3）

この関数アクティビティでは、一意の購買依頼の識別に必要な初期値がすべて設定されます。

購買依頼ステータスを処理中に設定し項目タイプとキーで更新（ノード4）

この関数アクティビティでは、文書ステータスが「処理中」に設定され、項目タイプと項目キーを使用して文書ヘッダーが更新されます。これは、購買依頼がワークフローに発行済であることを示します。

承認リストの検索（ノード5）

このアクティビティでは、Oracle iProcurementで作成された承認リストが検索されます。

ワークフローの承認モードを取得（ノード6）

この関数アクティビティでは、「PO: ワークフロー処理モード」プロファイル・オプションから値が取得されます。このプロファイル・オプションを使用すると、承認プロセスを「オンライン」モードと「バックグラウンド」モードのどちらで実行するかを選択できます。「バックグラウンド」モードと「オンライン」モードの定義は、「Oracle Purchasingのプロファイル・オプションとプロファイル・オプション・カテゴリ」を参照してください。

バックグラウンド・プロセスを待機（ノード7）

「PO: ワークフロー処理モード」プロファイル・オプションが「バックグラウンド」に設定されている場合、この関数アクティビティはワークフロー・バックグラウンド・エンジンによりこの文書がワークフローでの処理のために選択されるまで待機します。このアクティビティを使用すると、この文書の承認プロセスがバックグラウンドで完了する間に、次の購買アクティビティに進むことができます。関連項目: 『Oracle Workflow開発者ガイド』のワークフロー・バックグラウンド・エンジンの計画に関する項。

購買依頼属性を取得（ノード8）

この関数アクティビティでは、購買依頼ヘッダーおよび明細からキー値が取得され、ワークフロー属性に割り当てられます。

「購買依頼を検証」サブプロセスの概要

「購買依頼を検証」サブプロセスのプロパティを表示するには、対応するプロセス・アクティビティをナビゲータ・ツリーで選択し、「編集」メニューから「プロパティ」を選択します。「購買依頼を検証」サブプロセスの結果タイプは「発注文書検証」で、サブプロセスの完了時に結果が「検証失敗」または「検証通過」となることを示します。この結果は、「発注標準」項目タイプの「発注文書検証」参照タイプの参照コードに対応します。

このプロセス・アクティビティは実行不可で、最上位レベル・プロセスとしては開始できず、他の上位レベル・プロセスによりサブプロセスとしてコールされた場合にのみ実行できることを示します。

このサブプロセス・アクティビティでは、購買依頼が完了していることと情報が有効であることが確認されます。

このサブプロセスはノード1で始まります。

ノード2では、文書ステータスに承認処理との互換性があるかどうか（たとえば、ステータスが「消込済」、「凍結済」または「保留中」でないこと）がチェックされます。ノード4では、文書が完了しているかどうか（明細と配分がそれぞれ1つ以上含まれているかどうかの確認など）が検証されます。

ノード2で文書ステータスにより承認処理が許可されない場合、またはノード4で文書が未完了の場合は、それぞれノード8または9でその旨を示す通知が依頼者に送信されます。その後、ノード10では購買依頼ステータスがこのサブプロセスに入る前の値に戻され、ワークフローがノード11で終了します。購買依頼を変更して再発行するか、または新規に作成すると、購買依頼を承認のために発行する時点で購買依頼の承認ワークフローが再び開始されます。

ノード2および4で文書が検証を通過すると、ノード6では文書が承認のために発行されたことが「処理履歴」ウィンドウに記録されます。

文書承認処理マネージャがノード2または4で失敗すると、ノード3または5の通知アクティビティにより失敗通知が依頼者に送信されます。文書承認処理マネージャが正常に再起動された後、依頼者またはシステム管理者が通知に「再試行」で応答すると、ワークフローが続行されます。

関連項目: 文書ステータス・チェック、関連項目: 文書実行チェック

「購買依頼を検証」サブプロセスのアクティビティ

ここでは、「購買依頼検証」サブプロセスの各アクティビティについて、アクティビティの表示名順に説明します。

開始（ノード1）

これは標準の関数アクティビティで、単にサブプロセスの開始をマークします。

文書ステータスは承認処理を許可しますか?（ノード2）

このアクティビティでは、文書ステータスに承認処理との互換性があるかどうかがチェックされます。承認処理が許可される文書ステータスの例は、「未完了」、「処理中」および「事前承認済」です。

文書は完了していますか?（ノード4）

このアクティビティでは、購買依頼が完了しているかどうか（すべての数量が一致し、明細と配分がそれぞれ1つ以上存在するかどうかなど）が検証されます。

処理履歴に「送信」を記録（ノード6）

このアクティビティでは、文書が承認のために発行されたことを記録するために、PO_ACTION_HISTORY表に「発行処理」行が挿入されます。また、文書ステータスは「処理中」のため、転送先処理をシミュレートするためにNULLのACTION_CODEを含む追加の1行が挿入されます。文書マネージャでは、この行が検索されます。

文書マネージャ失敗（ノード3および5）

文書承認処理マネージャが失敗すると、依頼者はこの失敗通知を受け取ります。システム管理者が文書承認処理マネージャの再起動に成功した後、依頼者はワークフローを続行できるように「再試行」を選択して通知に応答する必要があります。

文書のステータス・チェック失敗（ノード8）

このアクティビティでは、文書のステータス・チェックに失敗したことを示す通知が依頼者に送信されます。関連項目: 文書ステータス・チェック。

文書の正誤チェック失敗（ノード9）

このアクティビティでは、文書の正誤チェックに失敗したことを示す通知が依頼者に送信されます。関連項目: 文書実行チェック。

購買依頼ステータスを当初ステータスに設定（ノード10）

文書がステータス・チェックまたは正誤チェックに失敗すると、この関数アクティビティでは、文書がこのプロセス・アクティビティに入る前のステータスに設定されます。

終了（ノード7および11）

この関数アクティビティは、プロセスの終了をマークします。アクティビティ自体には結果タイプはありませんが、プロセス内でこのアクティビティの各ノードには処理結果を割り当てる必要があります。処理結果は、アクティビティ・ノードのプロパティ・ページで割り当てます。「購買依頼検証」サブプロセス・アクティビティの結果タイプは「発注文書の検証」であるため、各終了アクティビティ・ノードの処理結果は、「発注文書の検証」参照タイプに属する参照コードのいずれか1つと一致する必要があります。

「開始時に予約」サブプロセスの概要

「開始時に予約」サブプロセスのプロパティを表示するには、対応するプロセス・アクティビティをナビゲータ・ツリーで選択し、「編集」メニューから「プロパティ」を選択します。「開始時に予約」サブプロセスの結果タイプは「発注アクティビティ実行」で、サブプロセスの完了時に結果が「アクティビティが実行されました」となることを示します。この結果は、「発注標準」項目タイプの「発注アクティビティ実行」参照タイプの参照コードに対応します。

このプロセス・アクティビティは実行不可で、最上位レベル・プロセスとしては開始できず、他の上位レベル・プロセスによりサブプロセスとしてコールされた場合にのみ実行できることを示します。

このサブプロセスはノード1で始まります。

予算引当が使用されている場合、このサブプロセスのノード7で、Oracle iProcurementで作成された購買依頼の承認プロセスの開始時に、予算の予約が試行されます。

まず、ノード2では、購買依頼がOracle iProcurementで個別に作成されたかどうかがチェックされます。Oracle iProcurementで個別に作成された場合、Oracle iProcurement購買依頼では「購買依頼インポート」は使用されず、Oracle内部表に直接保存されるため、「購買依頼インポート」のインタフェース・ソースをチェックする必要はありません。

ノード3では、Oracle iProcurementの前のWeb Requisitionsリリースで作成された購買依頼が個別にチェックされます（まだシステムにWeb Requisitionsによる購買依頼が残っている場合）。この種の購買依頼も「購買依頼インポート」を通過します。関連項目: 購買依頼インポート。

文書承認処理マネージャがノード7で失敗すると、ノード10で失敗通知が依頼者に送信されます。文書承認処理マネージャが正常に再起動された後、依頼者またはシステム管理者が通知に「再試行」で応答すると、ワークフローが続行されます。

「開始時に予約」サブプロセスのアクティビティ

ここでは、「開始時に予約」サブプロセスの各アクティビティについて、アクティビティの表示名順に説明します。

開始（ノード1）

これは標準の関数アクティビティで、単にサブプロセスの開始をマークします。

Webから購買依頼が作成されましたか?（ノード2）

このアクティビティでは、購買依頼がOracle iProcurementを介して作成されたかどうかが判別されます。

インタフェース・ソースの購買依頼はインポートですか?（ノード3）

このアクティビティでは、「購買依頼インポート」を介して送信された購買依頼がWeb Requisitionsリリース11で作成されたかどうかがチェックされます。

予算引当がオンで文書は未予約ですか?（ノード5）

この関数アクティビティでは、予算引当会計を使用しているかどうかと、文書がすでに予約済かどうかがチェックされます。

文書を予約（ノード7）

このアクティビティでは、文書に対する予算の予約が試行されます。

文書マネージャ失敗（ノード10）

文書承認処理マネージャが失敗すると、依頼者はこの失敗通知を受け取ります。システム管理者が文書承認処理マネージャの再起動に成功した後、依頼者はワークフローを続行できるように「再試行」を選択して通知に応答する必要があります。

終了（ノード4、6、8および9）

この関数アクティビティは、プロセスの終了をマークします。アクティビティ自体には結果タイプはありませんが、プロセス内でこのアクティビティの各ノードには処理結果を割り当てる必要があります。処理結果は、アクティビティ・ノードのプロパティ・ページで割り当てます。「開始時に予約」サブプロセス・アクティビティの結果タイプは「発注アクティビティ実行」であるため、各終了アクティビティ・ノードの処理結果は、「発注アクティビティ実行」参照タイプに属する参照コードのいずれか1つと一致する必要があります。

「承認権限を検証」サブプロセスの概要

「承認権限を検証」サブプロセスのプロパティを表示するには、対応するプロセス・アクティビティをナビゲータ・ツリーで選択し、「編集」メニューから「プロパティ」を選択します。「承認権限を検証」サブプロセスの結果タイプは「Yes/No」で、サブプロセスの完了時に結果が「Yes」または「No」となることを示します。この結果は、「標準」項目タイプの「Yes/No」参照タイプの参照コードに対応します。

このプロセス・アクティビティは実行不可で、最上位レベル・プロセスとしては開始できず、他の上位レベル・プロセスによりサブプロセスとしてコールされた場合にのみ実行できることを示します。

このサブプロセスはノード1で始まります。

ノード2では、「承認グループ」および「承認グループの割当」ウィンドウで定義された承認者の承認権限の制限がチェックされます。（関連項目: 承認グループの定義。関連項目: 承認グループの割当。）

承認者に十分な文書承認権限があれば、「転送先は指定されていますか?」関数アクティビティ（このサブプロセスの外側のワークフロー全体）が開始されます。十分な文書承認権限がなければ、「承認者の検索」プロセス・アクティビティが（このサブプロセスの外側で）開始されます。

文書承認処理マネージャがノード2で失敗すると、ノード3で失敗通知が承認者に送信されます。文書承認処理マネージャが正常に再起動された後、承認者またはシステム管理者が通知に「再試行」で応答すると、ワークフローが続行されます。

「承認権限を検証」サブプロセスのアクティビティ

ここでは、「承認権限の検証」サブプロセスの各アクティビティについて、アクティビティの表示名順に説明します。

開始（ノード1）

これは標準の関数アクティビティで、単にサブプロセスの開始をマークします。

承認者に権限がありますか?（ノード2）

この関数アクティビティでは、「承認グループ」および「承認グループの割当」ウィンドウで定義された承認限度に基づいて、承認者の権限が検証されます。関連項目: 承認グループの定義。関連項目: 承認グループの割当。

文書マネージャ失敗（ノード3）

文書承認処理マネージャが失敗すると、承認者はこの失敗通知を受け取ります。システム管理者が文書承認処理マネージャの再起動に成功した後、承認者はワークフローを続行できるように「再試行」を選択して通知に応答する必要があります。

終了（ノード4および5）

この関数アクティビティは、プロセスの終了をマークします。アクティビティ自体には結果タイプはありませんが、プロセス内でこのアクティビティの各ノードには処理結果が割り当てる必要があります。処理結果は、アクティビティ・ノードのプロパティ・ページで割り当てます。「承認権限の検証」サブプロセス・アクティビティの結果タイプは「Yes/No」であるため、各終了アクティビティ・ノードの処理結果は、「Yes/No」参照タイプに属する参照コードのいずれか1つと一致する必要があります。

「承認リスト経路」サブプロセスの概要

「承認リスト経路」サブプロセスのプロパティを表示するには、このプロセスをナビゲータ・ツリーで選択し、「編集」メニューから「プロパティ」を選択します。「承認リスト経路」サブプロセスの結果タイプは「発注承認リスト経路結果」で、プロセスの完了時に結果が「承認された文書」、「否認」または「差戻」となることを示します。これらの結果は、「発注標準」項目タイプの「発注承認リスト経路結果」参照タイプの参照コードに対応します。

このプロセス・アクティビティは実行不可で、最上位レベル・プロセスとしては開始できず、他の上位レベル・プロセスによりコールされた場合にのみ実行できることを示します。

このサブプロセスはノード1で始まります。

このサブプロセスは、購買依頼に追加承認が必要な場合に開始されます。ノード2では、承認リスト内の最初（または次）の承認者が検索されます。その承認者が無効な場合（購買依頼の発行直後に承認者が退職した場合など）、その承認者を除いた承認者リストがノード3で再作成されます。ノード3で承認リストを（システム障害や承認階層の問題などの原因で）再作成できなければ、このサブプロセスはノード4で終了し、購買依頼は依頼者に差し戻されます。

このサブプロセスは、ノード5で承認者の応答に応じて異なるノードに分岐します。否認の場合はノード6に、「転送」処理の場合はノード8に、承認の場合はノード9に、「承認して転送」処理の場合はノード10に分岐します。これらの各ノードでは、承認者の応答がPO_APPROVAL_LIST_HEADERS表とPO_APPROVAL_LIST_LINES表に記録され、それに従って処理履歴が更新されます。

ノード11では、承認経路を終了する前に承認リストが空かどうかがチェックされます。ノード12では、購買依頼が「事前承認済」かどうかがチェックされます。（購買依頼が承認済の場合は、後の「購買依頼を承認」サブプロセスまたは「承認前に予約」サブプロセスにより「承認済」ステータスに設定されるまで、「事前承認済」ステータスに設定されています。）

「承認リスト経路」サブプロセスのアクティビティ

ここでは、「承認リスト経路」サブプロセスの各アクティビティについて、アクティビティの表示名順に説明します。

次の承認者の取得（ノード2）

このアクティビティでは、承認リスト内の最初（または次）の承認者が検索されます。

無効な承認者に対する承認リストの再作成（ノード3）

承認者が無効な場合（購買依頼の発行直後に承認者が退職した場合など）、このアクティビティでは、その承認者を除いた承認リストが再作成されます。

注意: 承認者にログオン・ユーザー名がないと、このアクティビティでは、そのインスタンスでは承認リストが再作成されません。

承認者に通知（ノード5）

関連項目: 承認者に通知

否認処理の応答（ノード6）

関連項目: 否認処理の応答

承認処理の応答（ノード9）

関連項目: 承認処理の応答

承認および転送処理の応答（ノード10）

関連項目: 承認および転送処理の応答

承認リストは空白ですか?（ノード11）

このアクティビティでは、それ以上承認者がいないことが確認されます。承認者がいなければ、ワークフローにより購買依頼の承認が開始されます。承認者がいれば、ワークフローにより文書が承認へと導かれます。

購買依頼は事前承認済ですか?（ノード12）

この関数アクティビティでは、発注が事前承認済かどうかがチェックされます。「事前承認済」ステータスの文書は、適切な承認者により承認済で、承認のために他の承認者に転送するように選択されている文書です。または、承認済であっても予算が予約されていない文書です。文書は、「承認前に予約」サブプロセスまたは「購買依頼を承認」サブプロセスにより「承認済」ステータスに設定されるまでは事前承認済とみなされます。

「購買依頼の否認」サブプロセスの概要

「購買依頼の否認」サブプロセスのプロパティを表示するには、対応するプロセス・アクティビティをナビゲータ・ツリーで選択し、「編集」メニューから「プロパティ」を選択します。「購買依頼の否認」サブプロセスの結果タイプは「発注承認処理および文書検証」で、サブプロセスの完了時に結果が「無効な処理」または「有効な処理」となることを示します。この結果は、「発注標準」項目タイプの「発注承認処理および文書検証」参照タイプの参照コードに対応します。

このプロセス・アクティビティは実行不可で、最上位レベル・プロセスとしては開始できず、他の上位レベル・プロセスによりサブプロセスとしてコールされた場合にのみ実行できることを示します。

このサブプロセスはノード1で始まります。

ノード2では、文書のステータスが「否認済」に変更されます。サブプロセスで文書を否認できない場合（文書ステータスが「消込済」、「凍結済」または「保留中」に変更された場合など）、文書の否認に失敗したことを示す通知がノード5で依頼者に送信されます。（文書が否認されると、「主要購買依頼承認」プロセス内のこのサブプロセスの外側で否認通知が送信されます。）

文書承認処理マネージャがノード2で失敗すると、ノード4で失敗通知が承認者に送信されます。文書承認処理マネージャが正常に再起動された後、承認者またはシステム管理者が通知に「再試行」で応答すると、ワークフローが続行されます。

「購買依頼の否認」サブプロセスのアクティビティ

ここでは、「購買依頼の否認」サブプロセスの各アクティビティについて、アクティビティの表示名順に説明します。

開始（ノード1）

これは標準の関数アクティビティで、単にサブプロセスの開始をマークします。

購買依頼を否認（ノード2）

このアクティビティでは、購買依頼が「否認済」ステータスに設定されます。文書が引当済の場合は、引当も戻し処理されます。

文書を否認できません（ノード5）

このアクティビティでは、Oracle Purchasingが（ステータスが「消込済」、「凍結済」または「保留中」であるなどの原因で）文書を否認できなかったことを示す通知が承認者に送信されます。

文書マネージャ失敗（ノード4）

文書承認処理マネージャが失敗すると、承認者はこの失敗通知を受け取ります。システム管理者が文書承認処理マネージャの再起動に成功した後、承認者はワークフローを続行できるように「再試行」を選択して通知に応答する必要があります。

終了（ノード3および6）

この関数アクティビティは、プロセスの終了をマークします。アクティビティ自体には結果タイプはありませんが、プロセス内でこのアクティビティの各ノードには処理結果を割り当てる必要があります。処理結果は、アクティビティ・ノードのプロパティ・ページで割り当てます。「購買依頼の否認」サブプロセス・アクティビティの結果タイプは「発注承認処理と文書の検証」であるため、各終了アクティビティ・ノードの処理結果は、「発注承認処理と文書の検証」参照タイプに属する参照コードのいずれか1つと一致する必要があります。

「購買依頼を送信者に差戻す」サブプロセスの概要

「購買依頼を送信者に差戻す」サブプロセスのプロパティを表示するには、対応するプロセス・アクティビティをナビゲータ・ツリーで選択し、「編集」メニューから「プロパティ」を選択します。「購買依頼を送信者に差戻す」サブプロセスの結果タイプは「発注アクティビティ実行」で、サブプロセスの完了時に結果が「アクティビティが実行されました」となることを示します。この結果は、「発注標準」項目タイプの「発注アクティビティ実行」参照タイプの参照コードに対応します。

このプロセス・アクティビティは実行不可で、最上位レベル・プロセスとしては開始できず、他の上位レベル・プロセスによりサブプロセスとしてコールされた場合にのみ実行できることを示します。

「承認リスト経路」サブプロセス・アクティビティ（「主要購買依頼承認」プロセス内のこのサブプロセス・アクティビティの外側）で承認者が見つからなければ、「購買依頼を送信者に差戻す」サブプロセスにより購買依頼が発行者に差し戻されます。

このサブプロセスはノード1で始まります。ノード2では、文書がこのサブプロセスに入る前のステータスに設定されます。ノード3では、承認者が見つからなかったことを示す通知が依頼者に送信されます。ノード5では、承認者が見つからなかったことを示す通知が最終承認者に送信されます。ただし、ノード4で依頼者が単独または最終承認者であることも検出されると、サブプロセスはノード5をスキップしてノード6で終了します。そのため、依頼者が2件の通知を受け取ることはありません。

「購買依頼を送信者に差戻す」サブプロセスのアクティビティ

ここでは、「発行者への購買依頼差戻」サブプロセスの各アクティビティについて、アクティビティの表示名順に説明します。

開始（ノード1）

これは標準の関数アクティビティで、単にサブプロセスの開始をマークします。

購買依頼ステータスを当初ステータスに設定（ノード2）

このアクティビティでは、承認者が見つからなければ、購買依頼はこのプロセス・アクティビティに入る前のステータスに設定されます。

依頼者に使用可能な承認者がいないことを通知（ノード3）

このアクティビティでは、承認者が見つからなかった場合に、依頼者に通知が送信されます。

この通知のメッセージでは、「文書タイプ」項目属性を使用して2つのPL/SQL関数がコールされます。一方により文書内の明細がすべて取得されて通知に表示され、他方により文書の処理履歴が取得されて通知に表示されます。

送信者は最終承認者ですか?（ノード4）

この関数アクティビティでは、依頼者が単独または最終承認者でもあるかどうかがチェックされます。単独または最終承認者の場合、サブプロセスはノード5をスキップするため、依頼者には2件の通知は送信されません。

最終承認者に承認者が見つからないことを通知（ノード5）

このアクティビティでは、次の承認者が見つからなかったことを示す通知が最終承認者に送信されます。

この通知のメッセージでは、「文書タイプ」項目属性を使用して2つのPL/SQL関数がコールされます。一方により文書内の明細がすべて取得されて通知に表示され、他方により文書の処理履歴が取得されて通知に表示されます。

終了（ノード6）

この関数アクティビティは、プロセスの終了をマークします。アクティビティ自体には結果タイプはありませんが、プロセス内でこのアクティビティの各ノードには処理結果を割り当てる必要があります。処理結果は、アクティビティ・ノードのプロパティ・ページで割り当てます。「発行者への購買依頼差戻」サブプロセス・アクティビティの結果タイプは「発注アクティビティ実行」であるため、各終了アクティビティ・ノードの処理結果は、「発注アクティビティ実行」参照タイプに属する参照コードのいずれか1つと一致する必要があります。

「承認者に通知」サブプロセスの概要

「承認者に通知」サブプロセスのプロパティを表示するには、このプロセスをナビゲータ・ツリーで選択し、「編集」メニューから「プロパティ」を選択します。「承認者に通知」サブプロセスの結果タイプは「発注文書の承認処理」で、プロセスの完了時に結果が「承認」、「承認して転送」、「転送」または「否認」となることを示します。この結果は、「発注標準」項目タイプの「発注文書の承認処理」参照タイプの参照コードに対応します。

このプロセス・アクティビティは実行不可で、最上位レベル・プロセスとしては開始できず、他の上位レベル・プロセスによりコールされた場合にのみ実行できることを示します。

このサブプロセスはノード1で始まります。

ノード2では処理履歴が更新されます。処理履歴には、文書が承認者からの応答を待機していることが記録されます。（他のサブプロセスで使用される他の「処理履歴の更新」関数アクティビティとこの関数アクティビティが連携して動作し、「処理履歴」ウィンドウが更新されます。）

ノード3では、文書に承認が必要であることを示す通知が承認者に送信されます。「プロパティ」ウィンドウにノード3のタイムアウトを入力した場合は、ノード10で承認者に催促通知が送信されます。タイムアウトは、承認者から応答がない場合に、ワークフローが催促の送信前に待機する期間を示します。ノード10のタイムアウト値を入力した場合は、ノード17で別の催促が送信されます。

承認者が「承認して転送」または「転送」処理を実行すると、ノード4、8、11、15、18および22で、転送先が有効なユーザー名であることが確認されます。

このサブプロセスを含んでいる「承認リスト経路」サブプロセスの動作は、このノードでの承認者の応答（「承認して転送」、「承認」、「否認」または「転送」）に応じて異なります。

「承認者に通知」サブプロセスのアクティビティ

ここでは、「承認者に通知」サブプロセスの各アクティビティについて、アクティビティの表示名順に説明します。

処理履歴の更新（期待応答）（ノード2）

このアクティビティでは、文書が承認者からの応答を待機していることが処理履歴に記録されます。このアクティビティと他のサブプロセスで使用される他の「処理履歴の更新」アクティビティが連携して動作し、「処理履歴」ウィンドウが更新されます。

購買依頼通知を承認（ノード3）

このアクティビティでは、承認を求める通知が承認者に送信されます。

この通知のメッセージでは、「文書タイプ」項目属性を使用して2つのPL/SQL関数がコールされます。一方により文書内の明細がすべて取得されて通知に表示され、他方により文書の処理履歴が取得されて通知に表示されます。

購買依頼承認催促1（ノード10）

アクティビティの「プロパティ」ウィンドウでタイムアウト期間を指定し、指定した期間が経過しても承認応答を受信しない場合、このアクティビティにより初回の催促が送信されます。

この通知のメッセージでは、「文書タイプ」項目属性を使用して2つのPL/SQL関数がコールされます。一方により文書内の明細がすべて取得されて通知に表示され、他方により文書の処理履歴が取得されて通知に表示されます。

購買依頼承認催促2（ノード17）

アクティビティの「プロパティ」ウィンドウでタイムアウト期間を入力し、初回の催促後も承認応答を受信しない場合、このアクティビティにより2回目の催促が送信されます。

この通知のメッセージでは、「文書タイプ」項目属性を使用して2つのPL/SQL関数がコールされます。一方により文書内の明細がすべて取得されて通知に表示され、他方により文書の処理履歴が取得されて通知に表示されます。

転送先は有効ですか?（ノード4、8、11、15、18および22）

この関数アクティビティでは、承認通知への応答の「転送先」フィールドに入力された転送先名が有効なユーザー名かどうかがチェックされます。

「承認処理の応答」サブプロセスの概要

「承認処理の応答」サブプロセスのプロパティを表示するには、このプロセスをナビゲータ・ツリーで選択し、「編集」メニューから「プロパティ」を選択します。「承認処理の応答」サブプロセスの結果タイプは「なし」で、プロセスが完了しても「承認済」や「否認済」のような特定の結果で終了しないことを示します。

このプロセス・アクティビティは実行不可で、最上位レベル・プロセスとしては開始できず、他の上位レベル・プロセスによりサブプロセスとしてコールされた場合にのみ実行できることを示します。

このサブプロセスはノード1で始まります。

ノード2では、Oracle内部承認リスト表PO_APPROVAL_LIST_HEADERSおよびPO_APPROVAL_LIST_LINESが、承認者による承認で更新されます。ノード3では、処理履歴が「承認」処理で更新されます。ノード4で購買依頼が事前承認済でなければ、ノード6では承認者に承認権限があることが検証されます。ノード8では、購買依頼のステータスが「事前承認済」に設定されます。（購買依頼は、「購買依頼を承認」サブプロセスまたは「承認前に予約」サブプロセスにより実際に承認されるまで、このサブプロセス中は引き続き「事前承認済」とみなされます。）

「承認処理の応答」サブプロセスのアクティビティ

ここでは、「承認処理で応答」サブプロセスの各アクティビティについて、アクティビティの表示名順に説明します。

承認リスト応答の更新（ノード2）

このアクティビティでは、Oracle内部承認リスト表PO_APPROVAL_LIST_HEADERSおよびPO_APPROVAL_LIST_LINESが、承認者による承認で更新されます。

処理履歴の更新（承認）（ノード3）

このアクティビティでは、「処理履歴」ウィンドウ内の「承認」処理が記録されます。

ステータスを「事前承認済」に設定（ノード8）

次のいずれかの場合に、購買依頼のステータスが「事前承認済」に設定されます。

• 適切な承認者により承認済で、承認のために別の承認者に転送するように選択されている場合

• 承認済だが予算が予約されていない場合

• 文書は承認済だが、「購買依頼を承認」サブプロセスまたは「承認前に予約」サブプロセスで「承認済」ステータスに設定されていない場合

このアクティビティにより更新されるのは文書ステータスのみで、処理履歴は更新されません。

購買依頼は事前承認済ですか?（ノード4）

この関数アクティビティでは、発注が事前承認済かどうかがチェックされます。

承認処理に対する承認権限の検証（ノード6）

関連項目: 承認処理に対する承認権限の検証

「承認および転送処理の応答」サブプロセスの概要

「承認および転送処理の応答」サブプロセスのプロパティを表示するには、このプロセスをナビゲータ・ツリーで選択し、「編集」メニューから「プロパティ」を選択します。「承認および転送処理の応答」サブプロセスの結果タイプは「なし」で、プロセスが完了しても「承認済」や「否認済」のような特定の結果で終了しないことを示します。

このプロセス・アクティビティは実行不可で、最上位レベル・プロセスとしては開始できず、他の上位レベル・プロセスによりサブプロセスとしてコールされた場合にのみ実行できることを示します。

このサブプロセスはノード1で始まります。

ノード2では、処理履歴が「承認して転送」処理で更新されます。ノード3で購買依頼が承認済であることが検出された場合（ここでは「事前承認済」とみなされます）、この承認者の権限をノード4で検証する必要はありません。ノード6では、Oracle内部承認リスト表PO_APPROVAL_LIST_HEADERSおよびPO_APPROVAL_LIST_LINESが、承認者による「承認して転送」処理で更新されます。

ノード3で、この購買依頼が「事前承認済」ステータスでないことが検出されると、ノード4で承認者の承認権限が検証されます。承認者に十分な権限がなければ、ノード6で承認リスト表が更新され、ワークフロー（このサブプロセスの外側）で権限を持つ次の承認者が検索されます。

承認者に権限がある場合は、ノード5で購買依頼ステータスが「事前承認済」に設定されます。（購買依頼は、「購買依頼を承認」サブプロセスまたは「承認前に予約」サブプロセスで実際に承認されるまで、このサブプロセス中は「事前承認済」とみなされます。）

注意: このサブプロセス内のイベントの順序が重要です。ノード6は、ノード2および5から提供される情報に依存します。

「承認および転送処理の応答」サブプロセスのアクティビティ

ここでは、「承認および転送処理の応答」サブプロセスの各アクティビティについて、アクティビティの表示名順に説明します。

処理履歴の更新（承認/転送）（ノード2）

このアクティビティでは、「処理履歴」ウィンドウ内の「承認して転送」処理が記録されます。

承認処理および転送処理に対する承認権限の検証（ノード4）

関連項目: 承認処理および転送処理に対する承認権限の検証

ステータスを「事前承認済」に設定（ノード5）

次のいずれかの場合に、購買依頼のステータスが「事前承認済」に設定されます。

• 適切な承認者により承認済で、承認のために別の承認者に転送するように選択されている場合

• 承認済だが予算が予約されていない場合

• 文書は承認済だが、「購買依頼を承認」サブプロセスまたは「承認前に予約」サブプロセスで「承認済」ステータスに設定されていない場合

このアクティビティにより更新されるのは文書ステータスのみで、処理履歴は更新されません。

購買依頼は事前承認済ですか?（ノード3）

この関数アクティビティでは、購買依頼が事前承認済かどうかがチェックされます。

承認リスト応答の更新（ノード6）

このアクティビティでは、Oracle内部承認リスト表PO_APPROVAL_LIST_HEADERSおよびPO_APPROVAL_LIST_LINESが、承認者による「承認して転送」処理で更新されます。

「転送処理の応答」サブプロセスの概要

「転送処理の応答」サブプロセスのプロパティを表示するには、このプロセスをナビゲータ・ツリーで選択し、「編集」メニューから「プロパティ」を選択します。「転送処理の応答」サブプロセスの結果タイプは「なし」で、プロセスが完了しても「承認済」や「否認済」のような特定の結果で終了しないことを示します。

このプロセス・アクティビティは実行不可で、最上位レベル・プロセスとしては開始できず、他の上位レベル・プロセスによりサブプロセスとしてコールされた場合にのみ実行できることを示します。

このサブプロセスはノード1で始まります。

ノード2では、Oracle内部承認リスト表PO_APPROVAL_LIST_HEADERSおよびPO_APPROVAL_LIST_LINESが、承認者による「転送」処理で更新されます。ノード3では、「処理履歴」ウィンドウが「転送」処理で更新されます。

「転送処理の応答」サブプロセスのアクティビティ

ここでは、「送付処理で応答」サブプロセスの各アクティビティについて、アクティビティの表示名順に説明します。

承認リスト応答の更新（ノード2）

このアクティビティでは、Oracle内部承認リスト表PO_APPROVAL_LIST_HEADERSおよびPO_APPROVAL_LIST_LINESが、承認者による「転送」処理で更新されます。

処理履歴の更新（転送）（ノード3）

このアクティビティでは、「処理履歴」ウィンドウ内の「転送」処理が記録されます。

「否認処理の応答」サブプロセスの概要

「否認処理の応答」サブプロセスのプロパティを表示するには、このプロセスをナビゲータ・ツリーで選択し、「編集」メニューから「プロパティ」を選択します。「否認処理の応答」サブプロセスの結果タイプは「なし」で、プロセスが完了しても「承認済」や「否認済」のような特定の結果で終了しないことを示します。

このプロセス・アクティビティは実行不可で、最上位レベル・プロセスとしては開始できず、他の上位レベル・プロセスによりサブプロセスとしてコールされた場合にのみ実行できることを示します。

ノード2では、Oracle内部承認リスト表PO_APPROVAL_LIST_HEADERSおよびPO_APPROVAL_LIST_LINESが、承認者による否認で更新されます。ノード3では、「処理履歴」ウィンドウが「否認」処理で更新されます。

「否認処理の応答」サブプロセスのアクティビティ

ここでは、「否認処理の応答」サブプロセスの各アクティビティについて、アクティビティの表示名順に説明します。

承認リスト応答の更新（ノード2）

このアクティビティでは、Oracle内部承認リスト表PO_APPROVAL_LIST_HEADERSおよびPO_APPROVAL_LIST_LINESが、承認者による否認で更新されます。

処理履歴の更新（否認）（ノード 3）

このアクティビティでは、「処理履歴」ウィンドウ内の「否認」処理が記録されます。

「承認前に予約」サブプロセスの概要

「承認前に予約」サブプロセスのプロパティを表示するには、このプロセスをナビゲータ・ツリーで選択し、「編集」メニューから「プロパティ」を選択します。「承認前に予約」サブプロセスの結果タイプは「承認前に発注を予約」で、サブプロセスの完了時に結果が「転送」、「No」または「Yes」となることを示します。これらの結果は、「発注標準」項目タイプの「承認前に発注を予約」参照タイプの参照コードに対応します。

このプロセス・アクティビティは実行不可で、最上位レベル・プロセスとしては開始できず、他の上位レベル・プロセスによりコールされた場合にのみ実行できることを示します。

ノード2で引当が有効で文書の予算が予約されていないことが検出されると、ノード4で文書に対する予算の予約が試行されます。

予算を予約できなければ、ノード6で承認者に「文書を予約できません」という通知が送信されます。承認者は、より多くの予算が割当済だった場合などは、「承認文書」ウィンドウを使用して文書の予約を再試行してから、通知に「再試行」で応答するか、文書を否認するか、または予算の予約権限を持つ他の承認者に文書を転送する必要があります。

承認者が文書を転送すると、ノード7で転送先承認者が有効なユーザー名を持っているかどうかがチェックされます。有効なユーザー名を持っている場合は、ノード8で新規承認者の転送先/転送元情報が設定されます。

承認者が文書を否認すると、ノード10で購買依頼が否認されます。購買依頼を（ステータスが「消込済」、「凍結済」または「保留中」に変更されたなど、文書がステータス・チェックに失敗したことが原因で）否認できない場合、文書を否認できなかったことを示す通知がノード13で承認者に送信されます。

文書承認処理マネージャがノード4または10で失敗すると、ノード5または11の通知アクティビティにより失敗通知が承認者に送信されます。文書承認処理マネージャが正常に再起動された後、承認者またはシステム管理者が通知に「再試行」で応答すると、ワークフローが続行されます。

「承認前に予約」サブプロセスのアクティビティ

ここでは、「承認前に予約」サブプロセスの各アクティビティについて、アクティビティの表示名順に説明します。

予算引当がオンで文書は未予約ですか?（ノード2）

この関数アクティビティでは、予算引当会計を使用しているかどうかと、文書がすでに予約済かどうかがチェックされます。

文書を予約（ノード4）

このアクティビティでは、文書に対する予算の予約が試行されます。

文書マネージャ失敗（ノード5および11）

文書承認処理マネージャが失敗すると、承認者はこの失敗通知を受け取ります。システム管理者が文書承認処理マネージャの再起動に成功した後、承認者はワークフローを続行できるように「再試行」を選択して通知に応答する必要があります。

文書を予約できません（ノード6）

このアクティビティでは、Oracle Purchasingが購買依頼用の予算の予約に失敗したことが依頼者に通知され、失敗を解決するための指示が提供されます。承認者は、より多くの予算が割当済だった場合などは、「承認文書」ウィンドウを使用して文書の予約を再試行してから、通知に「再試行」で応答するか、文書を否認するか、または予算の予約権限を持つ他の承認者に文書を転送する必要があります。

転送先は有効ですか?（ノード7）

このアクティビティでは、承認通知への応答の「転送先」フィールドに入力された転送先名が有効なユーザー名かどうかがチェックされます。

転送に転送先と転送元を設定（ノード8）

承認者が文書を転送することで「文書を予約できません」通知に応答すると、この関数アクティビティにより「転送先」および「転送元」属性が再設定されます。

購買依頼を否認（ノード10）

このアクティビティでは、購買依頼が「否認済」ステータスに設定され、「処理履歴」ウィンドウ内で否認が記録されます。文書が引当済の場合は、引当も戻し処理されます。

文書を否認できません（ノード13）

このアクティビティでは、Oracle Purchasingが（ステータスが「消込済」、「凍結済」または「保留中」であるなどの原因で）購買依頼を正常に否認できなかったことを示す通知が承認者に送信されます。

「購買依頼を承認」サブプロセスの概要

「購買依頼を承認」サブプロセスのプロパティを表示するには、対応するプロセス・アクティビティをナビゲータ・ツリーで選択し、「編集」メニューから「プロパティ」を選択します。「購買依頼を承認」サブプロセスの結果タイプは「発注承認処理および文書検証」で、サブプロセスの完了時に結果が「無効な処理」または「有効な処理」となることを示します。この結果は、「発注標準」項目タイプの「発注承認処理および文書検証」参照タイプの参照コードに対応します。

このプロセス・アクティビティは実行不可で、最上位レベル・プロセスとしては開始できず、他の上位レベル・プロセスによりサブプロセスとしてコールされた場合にのみ実行できることを示します。

このサブプロセスはノード1で始まります。

ノード2では、文書が（「承認前に予約」サブプロセスなどで）承認済かどうかがチェックされます。承認済の場合、このサブプロセスはノード3で終了し、文書が承認済であることを示す通知がワークフローにより（「主要購買依頼承認」プロセス内で）依頼者に送信されます。

承認済でない場合は、ノード4で文書ステータスに承認処理との互換性があるかどうか（たとえば、ステータスが「消込済」、「凍結済」または「保留中」でないこと）がチェックされます。ノード 6では、文書が完了しているかどうか（明細と配分がそれぞれ1つ以上含まれているかどうかの確認など）が検証されます。

文書についてノード4で承認処理が許可されない場合、またはノード6で未完了の場合は、それぞれノード10および11で適切な通知が送信されます。その後、ノード12で文書がこのサブプロセスに入る前のステータスに戻され、ワークフローはノード13で終了します。

文書がノード4および6でチェックを通過すると、ノード8で購買依頼が承認されます。購買依頼情報や他の内部ワークフロー属性に変更があった場合は、ノード14でこれらの情報が取得されます。

文書承認処理マネージャがノード4、6または8で失敗すると、ノード5、7または9の通知アクティビティにより失敗通知が承認者に送信されます。文書承認処理マネージャが正常に再起動された後、承認者またはシステム管理者が通知に「再試行」で応答すると、ワークフローが続行されます。

関連項目: 文書ステータス・チェック、関連項目: 文書実行チェック

「購買依頼を承認」サブプロセスのアクティビティ

ここでは、「購買依頼承認」サブプロセスの各アクティビティについて、アクティビティの表示名順に説明します。

開始（ノード1）

これは標準の関数アクティビティで、単にサブプロセスの開始をマークします。

文書は承認されていますか?（ノード2）

予算引当を使用しており、予算が予約された時点で文書が「事前承認済」だった場合、そのステータスはすでに「承認済」に変更されています。

文書ステータスは承認処理を許可しますか?（ノード4）

承認処理を許可する文書ステータスの例は、「未完了」、「処理中」および「事前承認済」です。

文書は完了していますか?（ノード6）

このアクティビティでは、購買依頼が完了しているかどうか（すべての数量が一致し、明細と配分がそれぞれ1つ以上存在するかどうかなど）が検証されます。

購買依頼を承認（ノード8）

このアクティビティでは、購買依頼のステータスが「承認済」に設定されます。

購買依頼属性を取得（ノード14）

この関数アクティビティでは、購買依頼ヘッダーおよび明細のキー値に変更があった場合に、これらの値が取得され、ワークフロー属性に割り当てられます。

文書マネージャ失敗（ノード5、7および9）

文書承認処理マネージャが失敗すると、承認者はこの失敗通知を受け取ります。システム管理者が文書承認処理マネージャの再起動に成功した後、承認者はワークフローを続行できるように「再試行」を選択して通知に応答する必要があります。

文書のステータス・チェック失敗（ノード10）

この関数アクティビティでは、文書のステータス・チェックに失敗したことを示す通知が承認者に送信されます。関連項目: 文書ステータス・チェック。

文書の正誤チェック失敗（ノード11）

この関数アクティビティでは、文書の正誤チェックに失敗したことを示す通知が承認者に送信されます。関連項目: 文書実行チェック。

購買依頼ステータスを当初ステータスに設定（ノード12）

この関数アクティビティでは、文書がステータス・チェックまたは正誤チェックに失敗した場合、購買依頼が当初ステータスに設定されます。

終了（ノード3および13）

この関数アクティビティは、プロセスの終了をマークします。アクティビティ自体には結果タイプはありませんが、プロセス内でこのアクティビティの各ノードには処理結果を割り当てる必要があります。処理結果は、アクティビティ・ノードのプロパティ・ページで割り当てます。「購買依頼承認」サブプロセス・アクティビティの結果タイプは「発注承認処理と文書の検証」であるため、各終了アクティビティ・ノードの処理結果は、「発注承認処理と文書の検証」参照タイプに属する参照コードのいずれか1つと一致する必要があります。

「印刷文書」サブプロセスの概要

「印刷文書」サブプロセスのプロパティを表示するには、対応するプロセス・アクティビティをナビゲータ・ツリーで選択し、「編集」メニューから「プロパティ」を選択します。「印刷文書」サブプロセスの結果タイプは「発注アクティビティ実行」で、サブプロセスの完了時に結果が「アクティビティが実行されました」となることを示します。この結果は、「発注標準」項目タイプの「発注アクティビティ実行」参照タイプの参照コードに対応します。

このサブプロセスはノード1で始まります。

ノード2では、購買依頼が承認のために初めて発行されたときに「承認文書」ウィンドウで「印刷」が選択されたかどうかがチェックされます。「印刷」が選択された場合は、ノード4で文書が印刷されます。

「印刷文書」サブプロセスのアクティビティ

ここでは、「文書の印刷」サブプロセスの各アクティビティについて、アクティビティの表示名順に説明します。

開始（ノード1）

これは標準の関数アクティビティで、単にサブプロセスの開始をマークします。

ユーザーは文書印刷を希望していますか?（ノード2）

このアクティビティでは、購買依頼の初回発行時に「印刷」が選択されたかどうかがチェックされます。

印刷文書（ノード4）

購買依頼の初回発行時に「印刷」が選択された場合は、このアクティビティで文書が印刷されます。

終了（ノード3および5）

この関数アクティビティは、プロセスの終了をマークします。アクティビティ自体には結果タイプはありませんが、プロセス内でこのアクティビティの各ノードには処理結果を割り当てる必要があります。処理結果は、アクティビティ・ノードのプロパティ・ページで割り当てます。「文書の印刷」サブプロセス・アクティビティの結果タイプは「発注アクティビティ実行」であるため、各終了アクティビティ・ノードの処理結果は、「発注アクティビティ実行」参照タイプに属する参照コードのいずれか1つと一致する必要があります。

「承認処理に対する承認権限の検証」/「承認処理および転送処理に対する承認権限の検証」サブプロセスの概要

「承認処理に対する承認権限の検証」サブプロセスまたは「承認処理および転送処理に対する承認権限の検証」サブプロセスのプロパティを表示するには、そのプロセスをナビゲータ・ツリーで選択し、「編集」メニューから「プロパティ」を選択します。この2つのサブプロセスの結果タイプは「Yes/No」で、サブプロセスの完了時に結果が「Yes」または「No」となることを示します。この結果は、「標準」項目タイプの「Yes/No」参照タイプの参照コードに対応します。

このプロセス・アクティビティは実行不可で、最上位レベル・プロセスとしては開始できず、他の上位レベル・プロセスによりコールされた場合にのみ実行できることを示します。

「承認処理に対する承認権限の検証」サブプロセスは、承認者の承認権限を検証するために「承認処理の応答」サブプロセスによりコールされます。「承認処理および転送処理に対する承認権限の検証」サブプロセスは、承認者の承認権限を検証するために「承認および転送処理の応答」サブプロセスによりコールされます。

このサブプロセスはノード1で始まります。

サブプロセスのノード2では、「承認グループ」および「承認グループの割当」ウィンドウで定義された承認者の承認権限の制限がチェックされます。（関連項目: 承認グループの定義。関連項目: 承認グループの割当。）

文書承認処理マネージャがノード2で失敗すると、ノード3で失敗通知が承認者に送信されます。文書承認処理マネージャが正常に再起動された後、承認者またはシステム管理者が通知に「再試行」で応答すると、ワークフローが続行されます。

「承認処理に対する承認権限の検証」サブプロセスと「承認処理および転送処理に対する承認権限の検証」サブプロセスは、名称以外は同一です。名称が異なるのは、2つの異なるサブプロセスで使用されるためです。

「承認権限を検証」サブプロセスのアクティビティ

ここでは、「承認処理に対する承認権限の検証」サブプロセスおよび「承認処理および転送処理に対する承認権限の検証」サブプロセスの各アクティビティについて、アクティビティの表示名順に説明します。

承認者に権限がありますか?（ノード2）

この関数アクティビティでは、「承認グループ」および「承認グループの割当」ウィンドウで定義された承認限度に基づいて、承認者の権限が検証されます。関連項目: 承認グループの定義。関連項目: 承認グループの割当。

文書マネージャ失敗（ノード3）

文書承認処理マネージャが失敗すると、承認者はこの失敗通知を受け取ります。システム管理者が文書承認処理マネージャの再起動に成功した後、承認者はワークフローを続行できるように「再試行」を選択して通知に応答する必要があります。

発注承認ワークフロー

「通知要約」ウィンドウで発注またはリリースを承認のために発行するか処理を実行すると、Oracle PurchasingではバックグラウンドでOracle Workflowテクノロジを使用して承認プロセスが処理されます。Oracle Workflowでは、「文書承認とセキュリティの設定」の設定ステップに従って定義した承認管理と承認階層を使用して、文書が承認へと導かれます。Oracle Workflow Builderインタフェースを使用すると、承認プロセスを変更できます。

発注承認ワークフローは、Oracle Workflow Builderでダイアグラムとして参照可能なプロセスで構成されており、一部のオブジェクトとプロパティは変更可能です。各ワークフロー・プロセスは、個別の関数アクティビティで構成されています。

Oracle Purchasingでは、発注承認ワークフローは次の時点で開始されます。

• 「承認文書」ウィンドウで「承認のために発行」を選択（および「OK」を選択）した時点。関連項目: 承認のための文書発行。

• 「通知要約」ウィンドウで、承認のために未発行の文書を発行するように促す催促に応答した時点。

購買依頼承認ワークフローの詳細は、「購買依頼承認ワークフロー」を参照してください。

発注承認ワークフローのカスタマイズ

ワークフローをカスタマイズするには、Oracle Workflow Builderを使用します。ワークフローをカスタマイズした場合、そのワークフローの影響を受けるのは、カスタマイズ後に承認のために発行される文書のみです。

Oracle Workflow Builderを使用して、組織内の文書タイプごとに一意の承認ワークフローを作成することもできます。「文書タイプ」ウィンドウで、特定のワークフローを特定の文書タイプに関連付けます。関連項目: 文書タイプの定義。

ワークフロー・モニターを使用すると、ワークフロー・プロセス内の特定の文書の位置をたどることができます。関連項目: 『Oracle Workflowユーザーズ・ガイド』のワークフロー監視の概要に関する項。

Oracle Workflow Builderでワークフローを表示する手順は、次のとおりです。

1. 「ファイル」メニューから「オープン」を選択して、データベースに接続します。

   関連項目: 『Oracle Workflow開発者ガイド』の項目タイプのオープンと保存に関する項

   発注承認ワークフローの表示名は「発注承認」です。ワークフロー定義ファイル名はpoxwfpoa.wftです。

   

2. データ・ソースを拡張し、そのデータ・ソース内で「発注承認」項目タイプのブランチを拡張します。

3. 「発注承認」ブランチ内の「プロセス」ブランチを拡張し、プロセス・アクティビティをダブルクリックしてダイアグラムを表示します。

新規カスタム処理の作成

Oracle Purchasingに用意されているデフォルトの発注承認ワークフローを変更する方法と、それをコピーして新規ワークフローを作成する方法があります。「文書タイプ」ウィンドウを使用して、特定の文書タイプまたは営業単位用にカスタムの発注承認ワークフロー起動処理を選択できます。

文書や営業単位ごとに異なるワークフローを作成する場合は、項目タイプをコピーして名称変更するのではなく（発注承認1など）、「ワークフロー起動処理」をコピーして名称変更し、独自のカスタム・サブプロセスをコールするように変更することをお薦めします。全営業単位が同じ項目タイプを指し、その項目タイプに必要なデフォルトの項目属性と他のアクティビティを使用するようになりますが、営業単位の1つもカスタム起動処理を使用することになります。

重要: 新しい内部名を指定して新規ワークフロー・プロセスを作成すると、将来のアップグレードの実装に影響します。関連項目: アップグレードのサポート。

必要な変更

発注承認ワークフローに必須の変更はありません。ただし、この項ではOracle Purchasingの設定を完了し、「ワークフロー・オプションの選択」で説明したOracle Workflow設定ステップを実行していることを前提としています。

サポートされるカスタマイズとサポートされないカスタマイズ

この項では、発注承認ワークフローについて、変更可能な内容と変更不可の内容を説明します。変更可能な内容については、カスタマイズする際に注意を必要とする重要なガイドラインについても説明します。

ワークフローのカスタマイズ方法に関する重要情報は、『Oracle Workflow開発者ガイド』を参照してください。

カスタマイズの詳細は、この章の「「発注承認」項目タイプ」以降の各項を参照してください。これらの項では、発注承認ワークフローのメイン・プロセスのコンポーネントについて説明しています。まだ参照していない場合は、「カスタマイズのガイドライン」も参照してください。

重要: 以降の各項で、特定のワークフロー・オブジェクトがカスタマイズ可能オブジェクトのリストに記載されていない場合は、アクセス・レベルに関係なく変更しないでください。

属性

変更できるのは次の属性のみで、デフォルト値を変更します。

• 変更オーダーのヘッダーの包括購買契約の合計の許容範囲

• 変更オーダーのヘッダーの限度額の許容範囲

• 変更オーダーのヘッダーの発注合計の許容範囲

• 変更オーダーの明細の数量の許容範囲

• 変更オーダーの明細の単価の許容範囲

• 変更オーダーの明細のコミットされた数量の許容範囲

• 変更オーダーの明細の合意金額の許容範囲

• 変更オーダーの明細の限度価格の許容範囲

• 変更オーダーの出荷価格上書きの許容範囲

• 変更オーダーの出荷数量の許容範囲

• 変更オーダーの配分の発注数量の許容範囲

これらの属性の変更方法は、「変更オーダー承認のワークフロー・プロセス」を参照してください。

プロセス

プロセスを変更する場合は、データベース内のデータの整合性を維持するために基本的なフローをそのまま保つことが重要です。たとえば、「発注を検証」サブプロセスの「文書は完了していますか?」関数アクティビティを削除またはバイパスしないでください。この関数アクティビティを削除またはバイパスすると、データベース表に対する不完全データの挿入が許可される可能性があります。ただし、表へのデータ挿入を許可する前に、付加的なチェック（プロセスまたは関数アクティビティ）を追加することはできます。

プロセスを変更するには、そのフローの一部を置き換える方法と、新しい関数アクティビティを追加する方法があります。どちらの場合も、次のことに注意してください。

• デフォルト・プロセスのデフォルト関数アクティビティによって設定される属性は、デフォルト関数アクティビティを独自のものに置き換えた場合も設定される必要があります。つまり、そのプロセス内の関数アクティビティがSetItemAttr文を使用している場合、その関数アクティビティは後で他の関数アクティビティに使用される属性を設定します。したがって、新しい関数アクティビティも同じ属性を設定する必要があります。また、 SetItemUserKey文およびSetItemOwner文があれば、それも保存する必要があります。（カスタマイズの内容によっては、GetItemAttr文も保存してください。）

• デフォルト・プロセスが保守しているデータベースの状態は、カスタマイズしたプロセスでも保守する必要があります。つまり、カスタマイズしたプロセスの関数アクティビティでUpdate文またはInsert Into文を使用する場合、その関数アクティビティは、データベースの行を更新または挿入します。したがって、新規の関数アクティビティは、データベースを同じ状態に保守する必要があります。

  SetItemAttr文、GetItemAttr文、SetItemUserKey文、SetItemOwner文、Insert Into文またはUpdate文を使用するワークフロー関数アクティビティのリストを取得するには、PL/SQLスクリプトpowfcustを実行します。このスクリプトの実行手順は、「カスタマイズのガイドライン」を参照してください。

後述のプロセスは、ビジネス・プロセスのニーズに応じて変更できます。ただし、カスタマイズ後は、設定されていた属性と、デフォルト・プロセスによって保守されていたデータベースの状態は、カスタマイズ後のプロセスでも設定または保守する必要があります。

• 文書の変更に再承認が必要ですか。

• 承認者の検索

• 包括購買契約のすべての変更を取得

• 契約発注のすべての変更を取得

• 計画発注のすべての変更を取得

• リリースのすべての変更を取得

• 標準発注のすべての変更を取得

• 承認者に通知

• 文書の印刷プロセス

• 文書の印刷プロセス（変更オーダー）

• FAX文書プロセス

• FAX文書プロセス （変更オーダー）

次の各プロセスには独自の関数アクティビティを追加できますが、デフォルトの関数アクティビティは削除できません。

• 発注を承認して転送

• 発注の承認

• 発注の承認（変更オーダー）

• 変更オーダーの承認前予約

• 発注の転送

• 文書のすべての変更を取得

• 発注承認プロセス

• 発注承認最上位プロセス

• 発注否認サブプロセス

• 承認前に予約

• 発注を送信者に差戻す

• 承認権限を検証

• 発注を検証

通知

すべての通知は、個別のビジネス・ニーズにあわせて変更できます。ただし、通知に返信コードが含まれている場合は、カスタマイズした通知の「結果タイプ」がワークフロー・ダイアグラムでの遷移と一致していることを確認してください。関連項目: 『Oracle Workflow開発者ガイド』の通知アクティビティの作成に関する項。関連項目: 『Oracle Workflow開発者ガイド』のメッセージ結果に関する項。関連項目: 『Oracle Workflow開発者ガイド』のメッセージの作成に関する項。

関数アクティビティ

発注承認ワークフローの関数アクティビティは変更できません。

ただし、一部の関数アクティビティは、独自の関数アクティビティに置き換えることができます。関数アクティビティを置き換える場合は、それを含んでいるプロセスを変更します。関連項目: 前述の「プロセス」の「発注承認」プロセスのカスタマイズのガイドライン。

プロセスのデフォルト関数アクティビティを独自作成した関数アクティビティに置き換える場合は、次の点に注意する必要があります。

• 新しい関数アクティビティの結果タイプは、デフォルト・アクティビティの結果タイプと一致する必要があります。つまり、Oracle Workflow Builderにおける関数アクティビティの「結果タイプ」（「Yes/No」結果タイプなど）は、その関数アクティビティの対応するPL/SQLプロシージャで指定する結果タイプと一致する必要があります。また、関数アクティビティおよび対応するPL/SQLプロシージャに2つの結果（「Yes」と「No」など）がある場合は、ワークフロー・ダイアグラム内に2つの対応する遷移が（「Yes」に1つと「No」に1つ）存在することを確認してください。プロセスの結果タイプと遷移を変更する場合は、特別な遷移やチェックを削除またはバイパスしないように注意する必要があります。

• 前述の「プロセス」と同様に、デフォルト関数アクティビティにより設定されていた属性は、カスタマイズした関数アクティビティでも設定する必要があります。

• 前述の「プロセス」と同様に、デフォルト関数アクティビティにより維持されていたデータベースの状態は、カスタマイズした関数アクティビティでも維持する必要があります。

メッセージ

すべてのメッセージは、個々のビジネス・ニーズにあわせて変更できます。

参照タイプ

すべての参照タイプは、個々のビジネス・ニーズに合せて変更できます。

注意: 参照タイプを変更する場合は、その参照タイプを使用するすべてのアクティビティを変更対象とみなしてください。たとえば、参照タイプを「Yes/No」から他のタイプに変更すると、その参照タイプを使用するアクティビティについても、「結果タイプ」を「Yes/No」から新規作成した参照タイプに変更する必要があります。関連項目: 『Oracle Workflow開発者ガイド』の参照タイプに関する項。

発注承認項目タイプ

「発注承認」プロセスは、「発注承認」という項目タイプに関連付けられています。この項目タイプにより、使用可能な発注およびリリース承認ワークフロー・プロセスがすべて識別されます。「発注承認」に関連付けられているワークフロー・プロセスは、次のとおりです。

• 発注承認最上位プロセス

• 発注承認プロセス

• 発注を承認して転送

• 発注の承認

• 発注の承認（変更オーダー）*

• 変更オーダーの承認前予約*

• 文書の変更に再承認が必要ですか。*

• 承認者の検索

• 発注の転送

• 包括購買契約のすべての変更を取得

• 契約発注のすべての変更を取得*

• 文書のすべての変更を取得*

• 計画発注のすべての変更を取得*

• リリースのすべての変更を取得*

• 標準発注のすべての変更を取得*

• 承認者に通知

• 文書の印刷プロセス

• FAX文書プロセス

• 文書の印刷プロセス（変更オーダー）*

• FAX文書プロセス （変更オーダー）*

• 発注否認サブプロセス

• 承認前に予約

• 発注を送信者に差戻す

• 承認権限を検証

• 発注を検証

* これらは、別の項で説明する「変更オーダー」ワークフロー・プロセスです。関連項目: 変更オーダー承認のワークフロー・プロセス。

「発注承認」項目タイプには、多数の属性も関連付けられています。これらの属性は、Oracle Purchasingアプリケーション表内の情報を参照します。各属性は、関数アクティビティおよびプロセス全体の通知アクティビティによって使用され、保守されます。

「発注承認」ワークフロー項目タイプの属性

重要: すべての「変更オーダー」項目属性については、「変更オーダー・ワークフロー」の項に記載されています。関連項目: 変更オーダー承認のワークフロー・プロセス。

発注承認最上位プロセスの概要

「発注承認最上位プロセス」のプロパティを表示するには、そのプロセスをナビゲータ・ツリー内で選択し、「編集」メニューから「プロパティ」を選択します。このプロセスの結果タイプは「なし」で、プロセスが完了しても「承認済」や「否認済」のような特定の結果が戻されないことを示します。かわりに、そのサブプロセスが特定の結果を戻して終了します。

このプロセス・アクティビティは実行可能です。これは、ワークフロー・エンジンのCreateProcessおよびStartProcess APIのコールによってトップ・レベル・プロセスとして実行できることを示します。

このプロセス・アクティビティの「詳細」プロパティ・ページは、発注承認最上位プロセスにDEFAULT_ERRORと呼ばれるエラー・プロセスが関連付けられていることを示します。このエラー・プロセスは、プロセス内でエラーが発生したときにのみ実行されます。たとえば、従業員承認階層に含まれていない担当によって作成された発注に対して発注承認最上位プロセスを実行しようとすると、ワークフロー・エンジンは「承認者の検索」アクティビティを実行しようとしますがエラーになります。このエラーにより、「システム: エラー」項目タイプに関連したDEFAULT_ERRORが実行されます。現在、このプロセスでは、単に標準の「デフォルト・エラー通知」アクティビティが実行され、エラー関連情報が提供されるのみです。ビジネス・ニーズにあわせて、このプロセスをさらにカスタマイズできます。関連項目: 『Oracle Workflow開発者ガイド』のデフォルト・エラー・プロセスに関する項。

発注承認ワークフローは、Oracle Purchasingで承認のために発注を発行するか、または承認のための発注発行を求める催促通知に応答すると始まります。

このワークフローはノード1で始まります。

ノード2では、ワークフローに送信された前のバージョンの文書が未完了または否認済の場合、この文書に関する前の発注通知が削除されます。

ノード3では開始値が設定され、ノード5では発注ステータスが「処理中」に設定されます。ノード6では、プロセスの実行について設定されているパフォーマンス・モードが「オンライン」であるか「バックグラウンド」であるかが、「PO: ワークフロー処理モード」プロファイル・オプションに従って判別されます。ノード8では、発注属性（発注情報と内部ワークフロー属性）が取得されます。これらの開始アクティビティの詳細は、次の項を参照してください。

ノード9では、仕入先がOracle iSupplier Portal経由で変更（「納期」または「希望入手日」など）を行ったために文書の再承認が必要かどうかがチェックされます。仕入先による変更がOracle iSupplier Portalを介して承認済であれば、文書が発注変更や完全な再承認のために発行されることはなく、直接承認されます。

注意: ノード9では、Oracle iSupplier Portalを介して行われた変更をすべて承認できます。ノード9を削除すると、仕入先がOracle iSupplier Portalを介して行う変更は、変更オーダー・ワークフローにおける他の文書変更と同様に処理されます。関連項目: 変更オーダー承認のワークフロー・プロセス。

ノード10では、文書が新規かどうかがチェックされます。新規の場合、ワークフローはノード10からノード14の主要「発注承認」プロセスに移動し、文書が承認されます。文書が新規でない場合、Oracle Purchasingが（「文書タイプ」ウィンドウで）承認時に文書をアーカイブするように設定されていれば、変更オーダー・ワークフローが始まります（このように設定されていないと、変更オーダー・ワークフローは動作できません）。変更オーダー・ワークフローでは、ノード12ですべての文書変更が収集され、ノード13では変更について手動による再承認が必要であるか、単に自動的に承認可能かどうかが判別されます。ノード16では、予算引当会計が使用されている場合は、文書の予算予約が試行され、ノード18で変更が承認されます。ノード20では、文書が承認されたことを示す通知が送信され、「承認文書」ウィンドウで「印刷」が選択されている場合は、ノード21で文書が印刷されます。「承認文書」ウィンドウにFAX番号が入力されている場合は、ノード22で発注がFAX送信されます。

「発注承認最上位プロセス」のアクティビティ

ここでは、「発注承認最上位プロセス」の各アクティビティについて、アクティビティの表示名別に説明します。関数アクティビティによってコールされるPL/SQLストアド・プロシージャを除き、アクティビティのコンポーネントはすべてグラフィカルWorkflow Builderで作成できます。PL/SQLストアド・プロシージャはすべての関数アクティビティで実行されるため、Oracle RDBMS内で作成して格納する必要があります。PL/SQLストアド・プロシージャの命名規則は次のとおりです。

<PACKAGE>.<PROCEDURE> 

<PACKAGE>は全プロシージャをグループ化するパッケージの名称で、<PROCEDURE>はプロシージャ名を表します。

「発注承認」プロセスで使用されるパッケージおよびプロシージャ名を確認するには、各関数アクティビティの「プロパティ」ページを表示します。たとえば、「この文書の通知をすべて削除」関数アクティビティの場合は、<PACKAGE>.<PROCEDURE>名PO_REQAPPROVAL_INIT1.REMOVE_REMINDERを使用します。

「項目タイプの定義」Webページを使用すると、<PACKAGE>.<PROCEDURE>名を確認できます。関連項目: 『Oracle Workflow開発者ガイド』の「項目タイプの定義」Webページに関する項。

開始（ノード1）

これはプロセスの開始を単にマークする標準関数アクティビティです。

この文書の通知をすべて削除（ノード2）

この関数アクティビティでは、前にワークフローに発行済で、エラーまたは否認などの処理が原因で完了しなかった発注に関して、前の通知が削除されます。

ワークフローの開始値を設定（ノード3）

この関数アクティビティでは、作成者のユーザー名や転送先ユーザー名など、一意の発注の識別に必要な初期値がすべて設定されます。

ワークフロー・キーを使って発注ヘッダーを更新（ノード4）

この関数アクティビティでは、文書ヘッダーが、発注がワークフローに発行済であることを示す項目タイプと項目キーで更新されます。

発注ステータスを「処理中」に設定（ノード5）

発注を承認のために発行すると、そのステータスが「処理中」に変更されます。

ワークフローの承認モードを取得（ノード6）

この関数アクティビティでは、「PO: ワークフロー処理モード」プロファイル・オプションから値が取得されます。このプロファイル・オプションを使用すると、承認プロセスを「オンライン」モードと「バックグラウンド」モードのどちらで実行するかを選択できます。「バックグラウンド」モードと「オンライン」モードの定義は、「Oracle Purchasingのプロファイル・オプションとプロファイル・オプション・カテゴリ」を参照してください。

バックグラウンド・プロセスを待機（ノード7）

「PO: ワークフロー処理モード」プロファイル・オプションが「バックグラウンド」に設定されている場合、この関数アクティビティはワークフロー・バックグラウンド・エンジンによりこの文書がワークフローでの処理のために選択されるまで待機します。このアクティビティでは、この文書の承認プロセスがバックグラウンドで完了する間に、次の購買アクティビティに進むことができます。

発注属性を取得（ノード8）

この関数アクティビティでは、発注ヘッダーおよび明細からキー値が取得され、ワークフロー属性に割り当てられます。

Web仕入先から変更を実行済ですか?（ノード9）

これは、2つの数値、日付またはテキスト文字列の標準的な比較手段を提供する標準ワークフロー比較アクティビティです。ここでは、このアクティビティを使用して「Web仕入先が発行した文書」項目属性がチェックされます。文書変更がOracle iSupplier Portalを介して承認済（項目属性がYesを表す「Y」）の場合、文書が変更オーダーや完全な再承認のために発行されることはなく、直接承認されます。

関連項目: 『Oracle Workflow開発者ガイド』の比較アクティビティに関する項。関連項目: 『Oracle iSupplier Portal Implementation』。

これは新規文書ですか?（ノード10）

この関数アクティビティでは、新規発注であるか、または既存発注の変更であるかがチェックされます。（APPROVED_DATEがない場合は、新規文書とみなされます。）新規の場合、発注は「発注承認」プロセスを通過します。既存発注の変更の場合は、文書タイプの「アーカイブ時点」が「承認」に設定されていれば、変更オーダー承認プロセスを通過します。

格納先の承認フラグはYesにセットされていますか?（ノード11）

この関数アクティビティでは、「文書タイプ」ウィンドウで文書タイプの「アーカイブ時点」が「承認」と「印刷」のどちらに設定されているかがチェックされます。関連項目: 文書タイプの定義。「アーカイブ時点」が「承認」に設定され、前に承認済の文書が変更されている場合は、変更済発注またはリリース承認ワークフロー・プロセスが始まります。「アーカイブ時点」が「印刷」に設定されている場合、文書は承認プロセス全体を通過します。

発注承認プロセス（ノード14）

関連項目: 発注承認プロセス

文書のすべての変更を取得（ノード12）

関連項目: 文書のすべての変更を取得

文書の変更に再承認が必要ですか。（ノード13）

関連項目: 文書の変更に再承認が必要ですか。

変更オーダーの承認前予約（ノード16）

関連項目: 変更オーダーの承認前予約

発注の承認（変更オーダー）（ノード18）

関連項目: 発注の承認（変更オーダー）

発注承認済（ノード20）

この関数アクティビティでは、発注が承認されたことを示す通知が該当するユーザーに送信されます。

この通知のメッセージでは、「文書タイプ」項目属性を使用して2つのPL/SQL関数がコールされます。一方により文書内の明細がすべて取得されて通知に表示され、他方により文書の処理履歴が取得されて通知に表示されます。

文書の印刷プロセス（変更オーダー）（ノード21）

関連項目: 印刷、FAXおよびEメール文書プロセス

FAX文書プロセス （変更オーダー）またはEメール文書プロセス（変更オーダー）（ノード22）

関連項目: 印刷、FAXおよびEメール文書プロセス

発注送信イベントの呼出し（変更オーダー）（ノード23）

この関数アクティビティでは、文書がチェックされ、仕入先送信方法として「XML」が選択されているかどうかが確認されます。「XML」が選択されている場合は、文書をXMLで送信するイベントが呼び出されます。

このノードに続く処理には2つの経路があり、ワークフローでは両方がパラレルに実行されます。一方の経路では終了ノードで待機し、他方の経路ではソース・ルールと承認済仕入先リスト（ASL）を自動的に作成するサブプロセスにリンクします。

ソース・ルールおよびASLの作成（ノード24）

この関数アクティビティでは、「PO: ソース・ルールとASLの自動生成を許可」プロファイルがチェックされます。「購買文書インポート」から、またはユーザーにより「承認」ウィンドウで、このプロファイルが「Yes」に設定されて自動ソース・ルール生成が選択されている場合、このアクティビティではTRUEが戻され、「ソース・ルールおよびASLの作成」サブプロセスが起動されます。

ソース・ルールおよびASLの作成（ノード25）

このサブプロセスでは、承認対象の包括購買契約に含まれる全適格明細について、要求されたソース・ルールとASLが生成されます。このプロセスにより作成された例外は、「購買インタフェース・エラー・レポート」で確認できます。

PL/SQLエラーが発生しました

この通知アクティビティは、どのプロセス・ダイアグラムにも表示されませんが、関数アクティビティの実行時に内部PL/SQLエラーが発生した場合にワークフローで使用されます。この種のエラーが発生すると、この通知アクティビティにより、ワークフロー・エラーが発生したことを示す通知が文書所有者または承認者に送信されます。

発注承認プロセスの要約

「発注承認」プロセスのプロパティを表示するには、このプロセスをナビゲータ・ツリーで選択し、「編集」メニューから「プロパティ」を選択します。「発注承認」プロセスの結果タイプは「発注主要購買依頼承認プロセスの結果」で、プロセスの完了時に結果が「承認済」、「無効な処理」、「使用可能な承認者がいない」または「否認済」となることを示します。これらの結果は、「発注標準」項目タイプの「発注主要購買依頼承認プロセスの結果」参照タイプの参照コードに対応します。

このプロセス・アクティビティは実行不可で、最上位レベル・プロセスとしては開始できませんが、上位レベル・プロセスによりコールされた場合にサブプロセスとしてのみ実行できます。

「発注承認」プロセスは、新規発注が承認のために発行されるか、または発注変更が承認プロセス全体を通過する必要がある場合に開始されます。

このワークフローはノード1で始まります。

ノード2で発注が検証を通過すると、ノード4では、その文書タイプに対して「文書タイプ」ウィンドウで「所有者は承認可能」が有効化されているかどうかがチェックされます。ノード5で所有者に承認権限があることが検出されると、ノード6で所有者が転送先承認者を追加入力したかどうかがチェックされます。追加入力されている場合は、ノード7で発注が承認されて転送され、ノード8で承認者に通知されます。それ以外の場合は、ノード9で文書の承認が開始されます。

承認者が文書を承認するか、または承認して転送すると、文書ステータスが「事前承認済」になったかどうかがノード12でチェックされます。事前承認済の文書とは、最終承認者により承認済だが他の承認者にも転送された文書、または、予算引当会計を使用している場合は、承認対象だが予算が予約されていない文書です。このプロセス中、文書は承認後もノード9または23のサブプロセスで「承認済」ステータスに設定されるまでは事前承認済とみなされます。文書が事前承認済でなければ、ワークフローのノード5で承認者の現行の承認権限が検証されます。

承認者が文書を追加承認のために転送するか、応答しないか、またはノード4または5のアクティビティにより文書所有者に承認権限のないことが検出されると、ノード13で「承認者の検索」サブプロセスが始まります。ノード13で承認者が検出されると、ノード16で承認者のユーザー名が有効かどうかがチェックされます。有効な場合は、ノード17でその承認者に発注が転送されます。「承認者の検索」アクティビティに失敗した場合、または承認者のユーザー名が無効な場合、発注はノード14で発行者に差し戻されます。

承認者が検出されると、ノード8のサブプロセスでの承認者による応答が「転送」、「タイムアウト」（応答なし）、「承認」、「承認して転送」または「否認」のいずれであるかに応じて、ワークフローは異なるノードに分岐します。承認者が文書を否認した場合は、その旨を示す通知がノード21で購買担当（文書所有者）に送信されます。

予算引当会計を使用しており、文書の予算が予約されていない場合は、承認者全員が文書を承認すると、ノード9で承認前に文書の予算予約が試行されます。その後、ノード23で発注が承認され、ノード25で文書承認済通知が文書所有者に送信されます。発注の初回発行時に「承認文書」ウィンドウで「印刷」が選択されている場合は、ノード26で文書が印刷されます。「承認文書」ウィンドウでFAX番号が入力されている場合は、ノード27で発注がFAX送信されます。

発注承認プロセスのアクティビティ

ここでは、「発注承認」プロセスの各アクティビティを、前述のノード番号順に説明します。

開始（ノード1）

これはプロセスの開始を単にマークする標準関数アクティビティです。

発注を検証（ノード2）

関連項目: 発注を検証

所有者は承認が可能か?（ノード4）

この関数アクティビティでは、「文書タイプ」ウィンドウで特定の文書タイプに対して「所有者は承認可能」が有効化されているかどうかがチェックされます。関連項目: 文書タイプの定義。所有者が承認可能な場合、「承認権限を検証」サブプロセスにより所有者の承認権限が検証されます。所有者が承認可能でない場合は、「承認者の検索」サブプロセスが開始されます。

承認権限を検証（ノード5）

関連項目: 承認権限を検証

転送先は指定されていますか?（ノード6）

この関数アクティビティでは、「承認文書」または「通知要約」ウィンドウで転送先が指定されているかどうかがチェックされます。

発注を承認して転送（ノード7）

関連項目: 発注を承認して転送

承認者に通知（ノード8）

関連項目: 承認者に通知

承認前に予約（ノード9）

関連項目: 承認前に予約

発注は事前承認済ですか?（ノード12）

この関数アクティビティでは、発注が事前承認済かどうかがチェックされます。「事前承認済」ステータスの文書は、適切な承認者により承認済で、承認のために他の承認者に転送するように選択されている文書です。または、承認済であっても予算が予約されていない文書です。発注承認ワークフローでは、「承認前に予約」サブプロセスまたは「発注の承認」サブプロセスにより「承認済」ステータスに設定されるまでは、文書は事前承認済とみなされます。

承認者の検索（ノード13）

関連項目: 承認者の検索

発注を送信者に差戻す（ノード14）

関連項目: 発注を送信者に差戻す

転送ユーザー名は有効か?（ノード16）

この関数アクティビティでは、「承認者の検索」アクティビティにより検出された承認者のユーザー名が有効かどうかがチェックされます。

発注の転送（ノード17）

関連項目: 発注の転送

発注否認サブプロセス（ノード19）

関連項目: 発注の否認

発注否認済（ノード21）

承認者による否認が記録され、発注が購買担当に差し戻された後、このアクティビティにより、発注が否認されたことを示す通知が購買担当に送信されます。

発注を承認（ノード23）

関連項目: 発注の承認

発注承認済（ノード25）

この関数アクティビティでは、発注が承認されたことを示す通知が該当するユーザーに送信されます。

この通知のメッセージでは、「文書タイプ」項目属性を使用して2つのPL/SQL関数がコールされます。一方により文書内の明細がすべて取得されて通知に表示され、他方により文書の処理履歴が取得されて通知に表示されます。

発注送信イベントの呼出し（ノード26）

この関数アクティビティでは、文書がチェックされ、仕入先送信方法として「XML」が選択されているかどうかが確認されます。「XML」が選択されている場合は、文書をXMLで送信するイベントが呼び出されます。

このノードに続く処理には2つの経路があり、ワークフローでは両方がパラレルに実行されます。一方の経路では終了ノードで待機し、他方の経路ではソース・ルールと承認済仕入先リスト（ASL）を自動的に作成するサブプロセスにリンクします。

ソース・ルールおよびASLの作成

「購買文書インポート」から、またはユーザーにより「承認」ウィンドウで、自動ソース・ルール生成が選択されている場合、このアクティビティではTRUEが戻され、「ソース・ルールおよびASLの作成」サブプロセスが起動されます。

ソース・ルールおよびASLの作成（ノード27）

このサブプロセスでは、承認対象の包括購買契約の全適格明細について、要求されたソース・ルールと承認済仕入先リストが生成されます。

文書の印刷プロセス（ノード28）

関連項目: 印刷、FAXおよびEメール文書プロセス

FAX文書プロセス（ノード29）

関連項目: 印刷、FAXおよびEメール文書プロセス

この通知のメッセージでは、「文書タイプ」項目属性を使用して2つのPL/SQL関数がコールされます。一方により文書内の明細がすべて取得されて通知に表示され、他方により文書の処理履歴が取得されて通知に表示されます。

Eメール文書プロセス（ノード30）

関連項目: 印刷、FAXおよびEメール文書プロセス

終了（ノード3、10、11、15、18、20、22、24）

この関数アクティビティは、プロセスの終了をマークします。アクティビティ自体には結果タイプはありませんが、プロセス内でこのアクティビティの各ノードには処理結果が割り当てられています。処理結果は、アクティビティ・ノードのプロパティ・ページで割り当てます。「承認申請メイン・プロセス」アクティビティの結果タイプは「申請承認メイン・プロセス結果」であるため、各終了アクティビティ・ノードの処理結果は、「申請承認メイン・プロセス結果」参照タイプに属する参照コードのいずれか1つと一致する必要があります。

「発注を検証」サブプロセスの概要

「発注を検証」サブプロセスのプロパティを表示するには、対応するプロセス・アクティビティをナビゲータ・ツリーで選択し、「編集」メニューから「プロパティ」を選択します。「発注を検証」サブプロセスの結果タイプは「発注文書検証」で、サブプロセスの完了時に結果が「検証失敗」または「検証通過」となることを示します。この結果は、「発注標準」項目タイプの「発注文書検証」参照タイプの参照コードに対応します。

このサブプロセス・アクティビティは実行不可で、最上位レベル・プロセスとしては開始できず、上位レベル・プロセスによりコールされた場合にサブプロセスとしてのみ実行できることを示します。

このサブプロセス・アクティビティでは、発注が完了していることと情報が有効であることが確認されます。

このサブプロセスはノード1で始まります。

ノード2では、文書がオープンである（たとえば、最終消込済でない）かどうかがチェックされます。

ノード3では、文書ステータスに承認処理との互換性があるかどうか（たとえば、ステータスが「消込済」、「凍結済」または「保留中」でないこと）がチェックされます。ノード4では、文書が完了しているかどうか（明細と配分がそれぞれ1つ以上含まれているかどうかの確認など）が検証されます。

ノード3で文書ステータスにより承認処理が許可されない場合、またはノード4で文書が未完了の場合は、それぞれノード8または9でその旨を示す通知が文書所有者に送信されます。その後、ノード10では発注ステータスがこのサブプロセスに入る前の値に戻され、ワークフローがノード11で終了します。発注を変更して再発行するか、または新規に作成すると、発注を承認のために発行する時点で発注承認ワークフローが再び開始されます。

ノード3および4で文書が検証を通過すると、文書が承認のために発行されたことがノード12で「処理履歴」ウィンドウに記録されます。その後、「所有者は承認が可能か?」アクティビティが（「発注承認最上位プロセス」内の、このサブプロセスの外側で）開始されます。

文書承認処理マネージャがノード2、3または4で失敗すると、ノード5、6または7の通知アクティビティにより失敗通知が文書所有者に送信されます。文書承認処理マネージャが正常に再起動された後、文書所有者またはシステム管理者が通知に「再試行」で応答すると、ワークフローが続行されます。

関連項目: 文書ステータス・チェック、関連項目: 文書実行チェック

「発注を検証」サブプロセスのアクティビティ

ここでは、「発注を検証」サブプロセスの各アクティビティについて、アクティビティの表示名順に説明します。

開始（ノード1）

これは標準の関数アクティビティで、単にサブプロセスの開始をマークします。

オープン文書ステータス（ノード2）

この関数アクティビティでは、文書がオープンである（たとえば、最終消込済でない）かどうかがチェックされます。

文書ステータスは承認処理を許可しますか?（ノード3）

この関数アクティビティでは、文書ステータスに承認処理との互換性があるかどうかがチェックされます。承認処理が許可される文書ステータスの例は、「未完了」、「処理中」および「事前承認済」です。

文書は完了していますか?（ノード4）

この関数アクティビティでは、発注が完了しているかどうか（すべての数量が一致し、明細と配分がそれぞれ1つ以上存在するかどうかなど）が検証されます。

処理履歴に「送信」を記録（ノード12）

この関数アクティビティでは、文書が承認のために発行されたことを記録するために、PO_ACTION_HISTORY表に「発行処理」行が挿入されます。また、文書ステータスは「処理中」のため、転送先処理をシミュレートするためにNULLのACTION_CODEを含む追加の1行が挿入されます。文書マネージャでは、この行が検索されます。

文書マネージャ失敗（ノード5、6および7）

文書承認処理マネージャが失敗すると、文書所有者はこの失敗通知を受け取ります。システム管理者が文書承認処理マネージャの再起動に成功した後、所有者はワークフローを続行できるように「再試行」を選択して通知に応答する必要があります。

文書のステータス・チェック失敗（ノード8）

この関数アクティビティでは、文書のステータス・チェックに失敗したことを示す通知が文書所有者に送信されます。関連項目: 文書ステータス・チェック。

文書の正誤チェック失敗（ノード9）

この関数アクティビティでは、文書の正誤チェックに失敗したことを示す通知が文書所有者に送信されます。関連項目: 文書実行チェック。

発注ステータスをオリジナル・ステータスに設定（ノード10）

文書がステータス・チェックまたは正誤チェックに失敗すると、この関数アクティビティでは、文書がこのプロセス・アクティビティに入る前のステータスに設定されます。

終了（ノード11および13）

この関数アクティビティは、プロセスの終了をマークします。アクティビティ自体には結果タイプはありませんが、プロセス内でこのアクティビティの各ノードには処理結果を割り当てる必要があります。処理結果は、アクティビティ・ノードのプロパティ・ページで割り当てます。「発注を検証」サブプロセス・アクティビティの結果タイプは「発注文書の検証」であるため、各終了アクティビティ・ノードの処理結果は、「発注文書の検証」参照タイプに属する参照コードのいずれか1つと一致する必要があります。

「承認前に予約」サブプロセスの概要

「承認前に予約」サブプロセスのプロパティを表示するには、対応するプロセス・アクティビティをナビゲータ・ツリーで選択し、「編集」メニューから「プロパティ」を選択します。「承認前に予約」サブプロセスの結果タイプは「承認前に発注を予約」で、サブプロセスの完了時に結果が「転送」、「No」または「Yes」となることを示します。これらの結果は、「発注標準」項目タイプの「承認前に発注を予約」参照タイプの参照コードに対応します。

このサブプロセス・アクティビティは実行不可で、最上位レベル・プロセスとしては開始できず、上位レベル・プロセスによりコールされた場合にサブプロセスとしてのみ実行できることを示します。

このサブプロセスはノード1で始まります。

ノード2で引当が有効で予算が予約されていないことが検出されると、ノード4で文書に対する予算の予約が試行されます。

予算を予約できなければ、ノード6で承認者に「文書を予約できません」という通知が送信されます。承認者は、より多くの予算が割当済だった場合などは、「承認文書」ウィンドウを使用して文書の予約を再試行してから、通知に「再試行」で応答するか、文書を否認するか、または予算の予約権限を持つ他の承認者に文書を転送する必要があります。

承認者が文書を転送すると、ノード7で転送先承認者が有効なユーザー名を持っているかどうかがチェックされます。有効なユーザー名を持っている場合は、ノード8で新規承認者の転送先/転送元情報が設定されます。

承認者が文書を否認すると、ノード10で発注が否認されます。発注を（ステータスが「消込済」、「凍結済」または「保留中」に変更されたなど、文書がステータス・チェックに失敗したことが原因で）否認できない場合、文書を否認できなかったことを示す通知がノード13で承認者に送信されます。

文書承認処理マネージャがノード4または10で失敗すると、ノード5または11の通知アクティビティにより失敗通知が承認者に送信されます。文書承認処理マネージャが正常に再起動された後、承認者またはシステム管理者が通知に「再試行」で応答すると、ワークフローが続行されます。

「承認前に予約」サブプロセスのアクティビティ

ここでは、「承認前に予約」サブプロセスの各アクティビティについて、アクティビティの表示名順に説明します。

開始（ノード1）

これは標準の関数アクティビティで、単にサブプロセスの開始をマークします。

予算引当がオンで文書は未予約ですか?（ノード2）

この関数アクティビティでは、予算引当会計を使用しているかどうかと、文書がすでに予約済かどうかがチェックされます。

文書を予約（ノード4）

この関数アクティビティでは、文書に対する予算の予約が試行されます。

文書マネージャ失敗（ノード5および11）

文書承認処理マネージャが失敗すると、承認者はこの失敗通知を受け取ります。システム管理者が文書承認処理マネージャの再起動に成功した後、承認者はワークフローを続行できるように「再試行」を選択して通知に応答する必要があります。

文書を予約できません（ノード6）

このアクティビティでは、Oracle Purchasingが文書の予算予約に失敗したことが承認者に通知され、失敗を解決するための指示が提供されます。承認者は、より多くの予算が割当済だった場合などは、「承認文書」ウィンドウを使用して文書の予約を再試行してから、通知に「再試行」で応答するか、文書を否認するか、または予算の予約権限を持つ他の承認者に文書を転送する必要があります。

転送先は有効ですか?（ノード7）

この関数アクティビティでは、承認通知への応答の「転送先」フィールドに入力された転送先名が有効なユーザー名かどうかがチェックされます。

転送処理の転送先と転送元を設定（ノード8）

承認者が文書を転送することで「文書を予約できません」通知に応答すると、この関数アクティビティにより「転送先」および「転送元」属性が適切に再設定されます。

発注の否認（ノード10）

この関数アクティビティでは、文書のステータスが「否認済」に更新され、否認が「処理履歴」ウィンドウに記録されます。文書が引当済の場合は、引当も戻し処理されます。

文書を否認できません（ノード13）

このアクティビティでは、Oracle Purchasingが（ステータスが「消込済」、「凍結済」または「保留中」であるなどの原因で）文書を否認できなかったことを示す通知が承認者に送信されます。

終了（ノード3、9、12および14）

この関数アクティビティは、プロセスの終了をマークします。アクティビティ自体には結果タイプはありませんが、プロセス内でこのアクティビティの各ノードには処理結果を割り当てる必要があります。処理結果は、アクティビティ・ノードのプロパティ・ページで割り当てます。「承認前に予約」サブプロセス・アクティビティの結果タイプは「承認前に発注を予約」であるため、各終了アクティビティ・ノードの処理結果は、「承認前に発注を予約」参照タイプに属する参照コードのいずれか1つと一致する必要があります。

「承認権限を検証」サブプロセスの概要

「承認権限を検証」サブプロセスのプロパティを表示するには、対応するプロセス・アクティビティをナビゲータ・ツリーで選択し、「編集」メニューから「プロパティ」を選択します。「承認権限を検証」サブプロセスの結果タイプは「Yes/No」で、サブプロセスの完了時に結果が「Yes」または「No」となることを示します。この結果は、「標準」項目タイプの「Yes/No」参照タイプの参照コードに対応します。

このサブプロセス・アクティビティは実行不可で、最上位レベル・プロセスとしては開始できず、上位レベル・プロセスによりコールされた場合にサブプロセスとしてのみ実行できることを示します。

このサブプロセスはノード1で始まります。

サブプロセスのノード2では、「承認グループ」および「承認グループの割当」ウィンドウで定義された承認者の承認権限の制限がチェックされます。（関連項目: 承認グループの定義。関連項目: 承認グループの割当。）

承認者に十分な文書承認権限があれば、「転送先は指定されていますか?」関数アクティビティ（このサブプロセスの外側のワークフロー全体）が開始されます。十分な文書承認権限がなければ、「承認者の検索」プロセス・アクティビティが（このサブプロセスの外側で）開始されます。

文書承認処理マネージャがノード2で失敗すると、ノード4で失敗通知が承認者に送信されます。文書承認処理マネージャが正常に再起動された後、承認者またはシステム管理者が通知に「再試行」で応答すると、ワークフローが続行されます。

「承認権限を検証」サブプロセスのアクティビティ

ここでは、「承認権限の検証」サブプロセスの各アクティビティについて、アクティビティの表示名順に説明します。

開始（ノード1）

これは標準の関数アクティビティで、単にサブプロセスの開始をマークします。

承認者に権限がありますか?（ノード2）

この関数アクティビティでは、「承認グループ」および「承認グループの割当」ウィンドウで定義された承認限度に基づいて、承認者の権限が検証されます。関連項目: 承認グループの定義。関連項目: 承認グループの割当。

文書マネージャ失敗（ノード4）

文書承認処理マネージャが失敗すると、承認者はこの失敗通知を受け取ります。システム管理者が文書承認処理マネージャの再起動に成功した後、承認者はワークフローを続行できるように「再試行」を選択して通知に応答する必要があります。

終了（ノード3および5）

この関数アクティビティは、プロセスの終了をマークします。アクティビティ自体には結果タイプはありませんが、プロセス内でこのアクティビティの各ノードには処理結果が割り当てる必要があります。処理結果は、アクティビティ・ノードのプロパティ・ページで割り当てます。「承認権限の検証」サブプロセス・アクティビティの結果タイプは「Yes/No」であるため、各終了アクティビティ・ノードの処理結果は、「Yes/No」参照タイプに属する参照コードのいずれか1つと一致する必要があります。

「発注の承認」サブプロセスの概要

「発注の承認」サブプロセスのプロパティを表示するには、対応するプロセス・アクティビティをナビゲータ・ツリーで選択し、「編集」メニューから「プロパティ」を選択します。「発注の承認」サブプロセスの結果タイプは「発注承認処理および文書検証」で、サブプロセスの完了時に結果が「無効な処理」または「有効な処理」となることを示します。この結果は、「発注標準」項目タイプの「発注承認処理および文書検証」参照タイプの参照コードに対応します。

このサブプロセス・アクティビティは実行不可で、最上位レベル・プロセスとしては開始できず、上位レベル・プロセスによりコールされた場合にサブプロセスとしてのみ実行できることを示します。

このサブプロセスはノード1で始まります。

ノード2では、文書が（「承認前に予約」サブプロセスなどで）承認済かどうかがチェックされます。承認済の場合、このサブプロセスはノード3で終了し、文書が承認済であることを示す通知がワークフローにより（「発注承認」プロセス内で）購買担当に送信されます。

承認済でない場合は、文書の承認準備が完了しているかどうかがノード4で検証されます。承認準備が完了していない場合は、文書がステータス・チェックに失敗したこと（文書のステータスが「消込済」、「凍結済」または「保留中」に変更されたなど）を示す通知が、ノード5で承認者に送信されます。その後、ノード6で発注はこのサブプロセスに入る前のステータスに戻され、ワークフローはノード7で終了します。発注を変更して再発行するか、新規発注を作成する場合は、発注を承認のために発行する時点で発注承認ワークフローが開始されます。

文書がステータス・チェックを通過すると、ノード8では文書が完了しているかどうかが検証されます（明細と配分がそれぞれ1つ以上含まれているかどうかの確認など）。

文書が完了していなければ、ノード10でその旨を示す通知が承認者に送信されます。承認者は、「再試行」を選択して通知に応答するか（システム・レベルの問題がある場合）、または文書を否認できます。ノード13で文書を否認できない場合（文書のステータスが「消込済」、「凍結済」または「保留中」に変更されたなど）、ノード14で文書所有者に「文書を否認できません」という通知が送信されます。

文書がステータス・チェックを通過し、完了している場合は、ノード17で文書が承認され、発注情報と他の内部ワークフロー属性に変更があった場合は、ノード19でこれらの情報が取得されます。

文書承認処理マネージャがノード4、8、13または17で失敗すると、ノード9、11、12または18の通知アクティビティにより失敗通知が承認者に送信されます。文書承認処理マネージャが正常に再起動された後、承認者またはシステム管理者が通知に「再試行」で応答すると、ワークフローが続行されます。

関連項目: 文書ステータス・チェック、関連項目: 文書実行チェック

「発注の承認」サブプロセスのアクティビティ

ここでは、「発注の承認」サブプロセスの各アクティビティについて、アクティビティの表示名順に説明します。

開始（ノード1）

これは標準の関数アクティビティで、単にサブプロセスの開始をマークします。

文書は承認されていますか?（ノード2）

予算引当を使用しており、予算が予約された時点で文書が「事前承認済」だった場合、そのステータスはすでに「承認済」に変更されています。

文書ステータスは承認を許可しますか?（ノード4）

承認処理を許可する文書ステータスの例は、「未完了」、「処理中」および「事前承認済」です。

文書は完了していますか?（ノード8）

この関数アクティビティでは、文書が完了しているかどうか（すべての数量が一致し、明細と配分がそれぞれ1つ以上存在するかどうかなど）が検証されます。

発注を承認（ノード17）

このアクティビティでは、発注のステータスが「承認済」に設定されます。

発注属性を取得（ノード19）

この関数アクティビティでは、発注ヘッダーおよび明細のキー値に変更があった場合に、これらの値が取得され、ワークフロー属性に割り当てられます。

文書マネージャ失敗（ノード9、11、12および18）

文書承認処理マネージャが失敗すると、承認者はこの失敗通知を受け取ります。システム管理者が文書承認処理マネージャの再起動に成功した後、承認者はワークフローを続行できるように「再試行」を選択して通知に応答する必要があります。

文書のステータス・チェック失敗（ノード5）

このアクティビティでは、文書のステータス・チェックに失敗したことを示す通知が承認者に送信されます。関連項目: 文書ステータス・チェック。

発注ステータスをオリジナル・ステータスに設定（ノード6）

文書がステータス・チェックに失敗すると、この関数アクティビティでは、発注がこのプロセス・アクティビティに入る前のステータスに設定されます。

承認できません（ノード10）

このアクティビティでは、Oracle Purchasingが文書を承認できなかったことを示す通知が承認者に送信されます。

発注の否認（ノード13）

この関数アクティビティでは、文書のステータスが「否認済」に更新され、否認が「処理履歴」ウィンドウに記録されます。文書が引当済の場合は、引当も戻し処理されます。

文書を否認できません（ノード14）

このアクティビティでは、Oracle Purchasingが（ステータスが「消込済」、「凍結済」または「保留中」であるなどの原因で）文書を否認できなかったことを示す通知が承認者に送信されます。

終了（ノード3、7、15および16）

この関数アクティビティは、プロセスの終了をマークします。アクティビティ自体には結果タイプはありませんが、プロセス内でこのアクティビティの各ノードに処理結果を割り当てる必要があります。処理結果は、アクティビティ・ノードのプロパティ・ページで割り当てます。「発注の承認」サブプロセス・アクティビティの結果タイプは「発注承認処理と文書の検証」であるため、各終了アクティビティ・ノードの処理結果は、「発注承認処理と文書の検証」参照タイプに属する参照コードのいずれか1つと一致する必要があります。

印刷、FAXおよびEメール文書サブプロセスの概要

「印刷文書」プロセスまたは「FAX文書」プロセスのプロパティを表示するには、対応するプロセス・アクティビティをナビゲータ・ツリーで選択し、「編集」メニューから「プロパティ」を選択します。これらのサブプロセスの結果タイプは「発注アクティビティ実行」で、サブプロセスの完了時に結果が「アクティビティが実行されました」となることを示します。この結果は、「発注標準」項目タイプの「発注アクティビティ実行」参照タイプの参照コードに対応します。

文書の印刷プロセス

このサブプロセスはノード1で始まります。

ノード2では、発注が承認のために初めて発行されたときに「承認文書」ウィンドウで「印刷」が選択されたかどうかがチェックされます。「印刷」が選択された場合は、ノード4で文書が印刷されます。

FAX文書プロセス

「FAX文書」プロセスの外観と動作は「印刷文書」プロセスと同様ですが、ノード2では「承認文書」ウィンドウで「FAX」が選択されたかどうかがチェックされます。「FAX」が選択された場合、「承認文書」ウィンドウでFAX番号が入力されていれば、ノード4で自動的に文書がFAX送信されます。（FAX番号が指定されていなければ、文書は承認後にFAXサーバーに送信されます。CommercePathの設定に応じて、FAXサーバーに格納された文書の送信先と送信時期を選択できます。）

FAX機能を使用するには、CommercePath、またはCommercePath Fax Command Language（FCL）を使用するFAXソフトウェアをインストールする必要があります。

「Eメール文書」プロセス

「Eメール文書」プロセスの外観と動作は「印刷文書」プロセスと同様ですが、ノード2では「承認文書」ウィンドウで「Eメール」が選択されたかどうかがチェックされます。「Eメール」が選択された場合、「承認文書」ウィンドウでEメール・アドレスが入力されていれば、ノード4で自動的に文書のEメールが送信されます。

印刷、FAXおよびEメール文書サブプロセスのアクティビティ

ここでは、「印刷文書」、「FAX文書」および「Eメール文書」サブプロセスの各アクティビティについて、アクティビティの表示名順に説明します。

開始（ノード1）

これは標準の関数アクティビティで、単にサブプロセスの開始をマークします。

ユーザーは文書印刷を希望していますか?（ノード2）

この関数アクティビティでは、発注の初回発行時に「承認文書」ウィンドウで「印刷」が選択されたかどうかがチェックされます。

「FAX文書」プロセスの場合、「ユーザーは文書のFAXを希望するか?」関数アクティビティにより、「承認文書」ウィンドウで「FAX」が選択されたかどうかがチェックされます。FAX機能を使用するには、CommercePath、またはCommercePath Fax Command Language（FCL）を使用するFAXソフトウェアをインストールする必要があります。

印刷文書（ノード4）

発注の初回発行時に「承認文書」ウィンドウで「印刷」が選択された場合は、このアクティビティにより文書が印刷されます。

「FAX文書」プロセスの場合、「承認文書」ウィンドウでFAX番号が入力されていれば、「FAX文書」関数アクティビティにより文書が自動的にFAX送信されます。FAX機能を使用するには、CommercePath、またはCommercePath Fax Command Language（FCL）を使用するFAXソフトウェアをインストールする必要があります。

終了（ノード3および5）

この関数アクティビティは、プロセスの終了をマークします。アクティビティ自体には結果タイプはありませんが、プロセス内でこのアクティビティの各ノードには処理結果を割り当てる必要があります。処理結果は、アクティビティ・ノードのプロパティ・ページで割り当てます。「文書の印刷」サブプロセス・アクティビティの結果タイプは「発注アクティビティ実行」であるため、各終了アクティビティ・ノードの処理結果は、「発注アクティビティ実行」参照タイプに属する参照コードのいずれか1つと一致する必要があります。

「発注を承認して転送」サブプロセスの概要

「発注を承認して転送」サブプロセスのプロパティを表示するには、対応するプロセス・アクティビティをナビゲータ・ツリーで選択し、「編集」メニューから「プロパティ」を選択します。「発注を承認して転送」サブプロセスの結果タイプは「発注承認処理および文書検証」で、サブプロセスの完了時に結果が「無効な処理」または「有効な処理」となることを示します。この結果は、「発注標準」項目タイプの「発注承認処理および文書検証」参照タイプの参照コードに対応します。

このサブプロセス・アクティビティは実行不可で、最上位レベル・プロセスとしては開始できず、上位レベル・プロセスによりコールされた場合にサブプロセスとしてのみ実行できることを示します。

このサブプロセスはノード1で始まります。

ノード2では、文書ステータスに承認処理との互換性があるかどうか（たとえば、ステータスが「消込済」、「凍結済」または「保留中」でないこと）がチェックされます。文書ステータスに承認処理との互換性がなければ、文書がステータス・チェックに失敗したことを示す通知がノード3で承認者に送信されます。ノード4では、発注がこのサブプロセスに入る前のステータスに戻され、ワークフローがノード5で終了します。発注を変更して再発行するか、新規発注を作成する場合は、発注を承認のために発行する時点で発注承認ワークフローが開始されます。

文書がステータス・チェックを通過すると、ノード6では文書が完了しているかどうかが検証されます（明細と配分がそれぞれ1つ以上含まれているかどうかの確認など）。

文書が完了していなければ、ノード7でその旨を示す通知が承認者に送信されます。承認者は、「再試行」を選択して通知に応答するか、または文書を否認できます。ノード8で（ステータス・チェックに再び失敗したために）文書を否認できない場合、ノード11で文書所有者に「文書を否認できません」という通知が送信されます。

文書が完了している場合は、ノード13では発注の承認と転送が一度に実行され、発注情報と他の内部ワークフロー属性に変更があった場合は、ノード14でこれらの情報が取得されます。その結果、転送先承認者が（このサブプロセスの外側で）発注を承認し、「承認前に予約」または「発注の承認」により（このサブプロセスの外側で）発注ステータスが「承認済」に設定されるまで、発注のステータスは「事前承認済」になっています。

文書承認処理マネージャがノード2、6、8または13で失敗すると、ノード9、16、17または18の通知アクティビティにより失敗通知が承認者に送信されます。文書承認処理マネージャが正常に再起動された後、承認者またはシステム管理者が通知に「再試行」で応答すると、ワークフローが続行されます。

関連項目: 文書ステータス・チェック、関連項目: 文書実行チェック

「発注を承認して転送」サブプロセスのアクティビティ

ここでは、「発注の承認および送付」サブプロセスの各アクティビティについて、アクティビティの表示名順に説明します。

開始（ノード1）

これは標準の関数アクティビティで、単にサブプロセスの開始をマークします。

文書ステータスは承認を許可しますか?（ノード2）

承認処理を許可する文書ステータスの例は、「未完了」、「処理中」および「事前承認済」です。

文書は完了していますか?（ノード6）

この関数アクティビティでは、文書が完了しているかどうか（すべての数量が一致し、明細と配分がそれぞれ1つ以上存在するかどうかなど）が検証されます。

該当発注を承認して転送（ノード13）

この関数アクティビティでは、発注が承認されて次の承認者に転送されます。

発注属性を取得（ノード14）

この関数アクティビティでは、発注ヘッダーおよび明細のキー値に変更があった場合に、これらの値が取得され、ワークフロー属性に割り当てられます。

文書マネージャ失敗（ノード9、16、17および18）

文書承認処理マネージャが失敗すると、承認者はこの失敗通知を受け取ります。システム管理者が文書承認処理マネージャの再起動に成功した後、承認者はワークフローを続行できるように「再試行」を選択して通知に応答する必要があります。

文書のステータス・チェック失敗（ノード3）

この関数アクティビティでは、文書のステータス・チェックに失敗したことを示す通知が承認者に送信されます。関連項目: 文書ステータス・チェック。

発注ステータスをオリジナル・ステータスに設定（ノード4）

文書がステータス・チェックに失敗すると、この関数アクティビティでは、発注がこのプロセス・アクティビティに入る前のステータスに設定されます。

文書を承認できません（ノード7）

このアクティビティでは、文書が未完了であるためにOracle Purchasingが文書を承認できなかったことを示す通知が承認者に送信されます。

発注の否認（ノード8）

この関数アクティビティでは、文書のステータスが「否認済」に更新され、否認が「処理履歴」ウィンドウに記録されます。文書が引当済の場合は、引当も戻し処理されます。

文書を否認できません（ノード11）

このアクティビティでは、Oracle Purchasingが（ステータスが「消込済」、「凍結済」または「保留中」であるなどの原因で）文書を否認できなかったことを示す通知が承認者に送信されます。

終了（ノード5、10、12および15）

この関数アクティビティは、プロセスの終了をマークします。アクティビティ自体には結果タイプはありませんが、プロセス内でこのアクティビティの各ノードに処理結果を割り当てる必要があります。処理結果は、アクティビティ・ノードのプロパティ・ページで割り当てます。「発注の承認および送付」サブプロセス・アクティビティの結果タイプは「発注承認処理と文書の検証」であるため、各終了アクティビティ・ノードの処理結果は、「発注承認処理と文書の検証」参照タイプに属する参照コードのいずれか1つと一致する必要があります。

「承認者に通知」サブプロセスの概要

「承認者に通知」サブプロセスのプロパティを表示するには、対応するプロセス・アクティビティをナビゲータ・ツリーで選択し、「編集」メニューから「プロパティ」を選択します。「承認者に通知」サブプロセスの結果タイプは「発注文書の承認プロセス」で、サブプロセスの完了時に結果が「承認」、「承認して転送」、「転送」、「否認」または「タイムアウト」となることを示します。この結果は、「発注標準」項目タイプの「発注文書の承認プロセス」参照タイプの参照コードに対応します。

このサブプロセス・アクティビティは実行不可で、最上位レベル・プロセスとしては開始できず、上位レベル・プロセスによりコールされた場合にサブプロセスとしてのみ実行できることを示します。

このサブプロセスはノード1で始まります。

ノード2では、文書に承認が必要であることを示す通知が承認者に送信されます。

ノード2について「プロパティ」ウィンドウにタイムアウト値を入力した場合は、ノード12で承認者に催促通知が送信されます。タイムアウト値は、承認者から応答がない場合にワークフローが催促の送信前に待機する期間を示します。ノード12についてタイムアウト値を入力した場合は、ノード22で2件目の催促が送信されます。ノード22についてタイムアウト値を入力した場合は、ワークフローがノード33で終了（タイムアウト）します。

このサブプロセスでは、承認者が「承認」、「承認して転送」、「転送」または「タイムアウト」のいずれで応答するかに応じて、適切な転送先および転送元情報が設定されます。この情報は、「承認」処理の後はノード9、19および29で設定されます。「承認して転送」処理の後はノード4、14および24で、「転送」処理の後はノード7、17および27で、タイムアウトを入力した場合はサブプロセスのタイムアウト後にノード32で設定されます。

このサブプロセスを含んでいる「発注承認」プロセスの動作は、このノードでの承認者の応答（「承認して転送」、「承認」、「否認」または「転送」）に応じて異なります。

「承認者に通知」サブプロセスのアクティビティ

ここでは、「承認者に通知」サブプロセスの各アクティビティについて、アクティビティの表示名順に説明します。

開始（ノード1）

これは標準の関数アクティビティで、単にサブプロセスの開始をマークします。

発注通知を承認（ノード2）

このアクティビティでは、承認を求める通知が承認者に送信されます。

この通知のメッセージでは、「文書タイプ」項目属性を使用して2つのPL/SQL関数がコールされます。一方により文書内の明細がすべて取得されて通知に表示され、他方により文書の処理履歴が取得されて通知に表示されます。

発注承認催促1（ノード12）

アクティビティの「プロパティ」ウィンドウでタイムアウト期間を指定し、指定した期間が経過しても承認応答を受信しない場合、このアクティビティにより初回の催促が送信されます。

この通知のメッセージでは、「文書タイプ」項目属性を使用して2つのPL/SQL関数がコールされます。一方により文書内の明細がすべて取得されて通知に表示され、他方により文書の処理履歴が取得されて通知に表示されます。

発注承認催促2（ノード22）

アクティビティの「プロパティ」ウィンドウでタイムアウト期間を入力し、初回の催促後も承認応答を受信しない場合、このアクティビティにより2回目の催促が送信されます。

この通知のメッセージでは、「文書タイプ」項目属性を使用して2つのPL/SQL関数がコールされます。一方により文書内の明細がすべて取得されて通知に表示され、他方により文書の処理履歴が取得されて通知に表示されます。

承認処理の転送先と転送元を設定（ノード9、19および29）

この関数アクティビティでは、「承認」処理の後に「転送先」および「転送元」属性が再設定されます。

転送先は有効ですか?（ノード3、6、13、16、23および26）

この関数アクティビティでは、承認通知への応答の「転送先」フィールドに入力された転送先名が有効なユーザー名かどうかがチェックされます。

承認と転送処理の転送先と転送元を設定（ノード4、14および24）

この関数アクティビティでは、「承認して転送」処理の後に「転送先」および「転送元」属性が再設定されます。

転送処理の転送先と転送元を設定（ノード7、17および27）

この関数アクティビティでは、「転送」処理の後に「転送先」および「転送元」属性が再設定されます。

タイムアウトの転送先と転送元を設定（ノード32）

この関数アクティビティでは、前のアクティビティのタイムアウト後に（タイムアウトが関連付けられている場合）、「転送先」および「転送元」属性が再設定されます。

終了（ノード5、8、10、11、15、18、20、21、25、28、30、31および33）

この関数アクティビティは、プロセスの終了をマークします。アクティビティ自体には結果タイプはありませんが、プロセス内でこのアクティビティの各ノードには処理結果を割り当てる必要があります。処理結果は、アクティビティ・ノードのプロパティ・ページで割り当てます。「承認者に通知」サブプロセス・アクティビティの結果タイプは「PO文書承認処理プロセス」であるため、各終了アクティビティ・ノードの処理結果は、「PO文書承認処理プロセス」参照タイプに属する参照コードのいずれか1つと一致する必要があります。

「承認者の検索」サブプロセスの概要

「承認者の検索」サブプロセスのプロパティを表示するには、対応するプロセス・アクティビティをナビゲータ・ツリーで選択し、「編集」メニューから「プロパティ」を選択します。「承認者の検索」サブプロセスの結果タイプは「Yes/No」で、サブプロセスの完了時に結果が「Yes」または「No」となることを示します。この結果は、「標準」項目タイプの「Yes/No」参照タイプの参照コードに対応します。

このサブプロセス・アクティビティは実行不可で、最上位レベル・プロセスとしては開始できず、上位レベル・プロセスによりコールされた場合にサブプロセスとしてのみ実行できることを示します。

このプロセスでは、次のいずれかの条件に該当する場合に、承認階層内で次の承認者が検索されます。

• 「承認権限を検証」により、文書所有者に「承認グループ」および「承認グループの割当」ウィンドウで定義されている文書承認権限が付与されていないことが判別された場合。（関連項目: 承認グループの定義。関連項目: 承認グループの割当。）

• 「所有者は承認が可能か?」により、「文書タイプ」ウィンドウで特定の文書タイプの「所有者は承認可能」が選択されていないことが検出された場合。関連項目: 文書タイプの定義。

• 「承認者に通知」プロセス中に承認者が文書を別の承認者に転送した場合、またはタイムアウト機能が設定されている場合は、特定期間の後に応答しない場合。

このサブプロセスはノード1で始まります。

ノード2で転送先承認者が検出されなければ、ノード4でデフォルト承認階層（購買担当が「承認文書」ウィンドウに入力する特定の承認階層、またはOracle Purchasingのデフォルト承認階層）が取得されます。

ノード5では、転送方法がチェックされます。転送方法が「直接」の場合、発注はノード13以降で十分な承認権限を持つ最初の承認者に送信されます。転送方法が「階層」の場合は、ノード6以降で十分な承認権限を持つ承認者に到達するまで、階層内の各承認者が処理を実行する必要があります。

ノード6および13では、職階階層を使用しているかどうかがチェックされます。職階階層を使用している場合は、ノード7および14で職階階層を使用して次の承認者が検索されます。職階階層を使用していない場合は、ノード10および19で従業員/管理者階層を使用して次の承認者が検索されます。

文書承認処理マネージャがノード16または21で失敗すると、ノード17または22の通知アクティビティにより失敗通知が承認者に送信されます。文書承認処理マネージャが正常に再起動された後、承認者またはシステム管理者が通知に「再試行」で応答すると、ワークフローが続行されます。

「承認者の検索」サブプロセスのアクティビティ

ここでは、「承認者の検索」サブプロセスの各アクティビティについて、アクティビティの表示名順に説明します。

開始（ノード1）

これは標準の関数アクティビティで、単にサブプロセスの開始をマークします。

転送先は指定されていますか?（ノード2）

この関数アクティビティでは、購買担当または承認者が転送先ユーザー名を入力したかどうかがチェックされます。

承認経路を取得（ノード4）

この関数アクティビティでは、承認階層（購買担当が「承認文書」ウィンドウに入力した特定の承認階層、またはOracle Purchasingのデフォルト承認階層）が取得されます。

転送モードを取得（ノード5）

この関数アクティビティでは、転送モードとして「階層」または「直接」が取得されます。「直接」モードでは、発注は十分な承認権限を持つ最初の承認者に送られます。「階層」モードでは、十分な承認権限を持つ承認者に到達するまで、階層内の各承認者が処理を実行する必要があります。

発注承認の階層を使用していますか。（ノード6および13）

この関数アクティビティでは、承認に職階階層が使用されているかどうかがチェックされます。関連項目: 文書承認とセキュリティの設定。

H.R.内で次のマネージャを取得（ノード10および19）

従業員/管理者関連階層が使用されている場合は、このアクティビティにより購買担当のマネージャが取得されます。表HR_EMPLOYEESおよびHR_ASSIGNMENTSを使用して、購買担当の最初のマネージャが取得されます。

承認階層の最初のマネージャを取得（ノード7および14）

職階階層が使用されている場合は、この関数アクティビティにより表PO_EMPLOYEE_HIERARCHIESおよびHR_EMPLOYEESを使用して購買担当の最初のマネージャが取得されます。

承認者に権限がありますか?（ノード16および21）

この関数アクティビティでは、承認者の承認権限が「承認グループ」および「承認グループの割当」ウィンドウで定義された権限の制限に基づいているかどうかが検証されます。

文書マネージャ失敗（ノード17および22）

文書承認処理マネージャが失敗すると、承認者はこの失敗通知を受け取ります。システム管理者が文書承認処理マネージャの再起動に成功した後、承認者はワークフローを続行できるように「再試行」を選択して通知に応答する必要があります。

終了（ノード3、8、9、11、12、15、18、20および23）

この関数アクティビティは、プロセスの終了をマークします。アクティビティ自体には結果タイプはありませんが、プロセス内でこのアクティビティの各ノードには処理結果を割り当てる必要があります。処理結果は、アクティビティ・ノードのプロパティ・ページで割り当てます。「承認者の検索」サブプロセス・アクティビティの結果タイプは「Yes/No」であるため、各終了アクティビティ・ノードの処理結果は、「Yes/No」参照タイプに属する参照コードのいずれか1つと一致する必要があります。

「発注の転送」サブプロセスの概要

「発注の転送」サブプロセスのプロパティを表示するには、対応するプロセス・アクティビティをナビゲータ・ツリーで選択し、「編集」メニューから「プロパティ」を選択します。「発注の転送」サブプロセスの結果タイプは「発注承認処理および文書検証」で、サブプロセスの完了時に結果が「無効な処理」または「有効な処理」となることを示します。この結果は、「発注標準」項目タイプの「発注承認処理および文書検証」参照タイプの参照コードに対応します。

このサブプロセス・アクティビティは実行不可で、最上位レベル・プロセスとしては開始できず、上位レベル・プロセスによりコールされた場合にサブプロセスとしてのみ実行できることを示します。

このサブプロセスはノード1で始まります。

「承認者の検索」サブプロセスのアクティビティにより（このサブプロセスの外側のワークフロー全体で）承認者が検出されると、このサブプロセスにより発注が次の承認者に転送されます。

ノード2では、発注が事前承認済かどうか（最終承認者により承認済だが他の承認者にも転送されるか、または予算引当会計を使用している場合は承認済だが予算が予約されていないかどうか）がチェックされます。事前承認済でなければ、ノード4で「処理中」ステータスの発注が転送されます。事前承認済であれば、ノード8で「事前承認済」ステータスの発注が転送されます。発注承認ワークフローでは、「承認前に予約」サブプロセスまたは「発注の承認」サブプロセスにより「承認済」ステータスに設定されるまで、文書は引き続き事前承認済とみなされます。

文書の転送後、発注情報や他の内部ワークフロー属性に変更があった場合は、ノード6および10でこれらの情報が取得されます。

文書承認処理マネージャがノード4または8で失敗すると、ノード5または9の通知アクティビティにより文書の転送者に失敗通知が送信されます。文書承認処理マネージャが正常に再起動された後、承認者またはシステム管理者が通知に「再試行」で応答すると、ワークフローが続行されます。

「発注の転送」サブプロセスのアクティビティ

ここでは、「発注の送付」サブプロセスの各アクティビティについて、アクティビティの表示名順に説明します。

開始（ノード1）

これは標準の関数アクティビティで、単にサブプロセスの開始をマークします。

発注は事前承認済ですか?（ノード2）

この関数アクティビティでは、発注が事前承認済かどうかがチェックされます。「事前承認済」ステータスの文書は、適切な承認者により承認済で、承認のために他の承認者に転送するように選択されている文書です。または、承認済であっても予算が予約されていない文書です。発注承認ワークフローでは、「承認前に予約」サブプロセスまたは「発注の承認」サブプロセスにより「承認済」ステータスに設定されるまでは、文書は事前承認済とみなされます。

ステータスが「処理中」の発注の転送（ノード4）

発注ステータスが「未完了」の場合は、このアクティビティによりステータスが「処理中」に設定され、発注が承認者に転送され、文書の処理履歴が「転送」処理で更新されます。

ステータスが「事前承認済」の発注の転送（ノード8）

発注ステータスが「事前承認済」の場合は、このアクティビティにより発注がそのステータスのままで次の承認者に転送されます。

発注属性を取得（ノード6および10）

この関数アクティビティでは、発注ヘッダーおよび明細のキー値に変更があった場合に、これらの値が取得され、ワークフロー属性に割り当てられます。

文書マネージャ失敗（ノード5および9）

文書承認処理マネージャが失敗すると、文書の転送者はこの失敗通知を受け取ります。システム管理者が文書承認処理マネージャの再起動に成功した後、承認者はワークフローを続行できるように「再試行」を選択して通知に応答する必要があります。

終了（ノード3、7および11）

この関数アクティビティは、プロセスの終了をマークします。アクティビティ自体には結果タイプはありませんが、プロセス内でこのアクティビティの各ノードに処理結果を割り当てる必要があります。処理結果は、アクティビティ・ノードのプロパティ・ページで割り当てます。「発注の送付」サブプロセス・アクティビティの結果タイプは「発注承認処理と文書の検証」であるため、各終了アクティビティ・ノードの処理結果は、「発注承認処理と文書の検証」参照タイプに属する参照コードのいずれか1つと一致する必要があります。

「発注を送信者に差戻す」サブプロセスの概要

「発注を送信者に差戻す」サブプロセスのプロパティを表示するには、対応するプロセス・アクティビティをナビゲータ・ツリーで選択し、「編集」メニューから「プロパティ」を選択します。「発注を送信者に差戻す」サブプロセスの結果タイプは「発注アクティビティ実行」で、サブプロセスの完了時に結果が「アクティビティが実行されました」となることを示します。この結果は、「発注標準」項目タイプの「発注アクティビティ実行」参照タイプの参照コードに対応します。

このサブプロセス・アクティビティは実行不可で、最上位レベル・プロセスとしては開始できず、上位レベル・プロセスによりコールされた場合にサブプロセスとしてのみ実行できることを示します。

「承認者の検索」サブプロセス・アクティビティにより（このサブプロセス・アクティビティの外側の「発注承認」プロセス内で）承認者が検出されなければ、「発注を送信者に差戻す」サブプロセスにより発注が購買担当に差し戻されます。

このサブプロセスはノード1で始まります。ノード2では、文書がこのサブプロセスに入る前のステータスに設定されます。ノード3では、承認者が見つからなかったことを示す通知が購買担当に送信されます。ノード5では、承認者が見つからなかったことを示す通知が最終承認者に送信されます。ただし、ノード4で購買担当が単独または最終承認者であることも検出されると、サブプロセスはノード5をスキップしてノード6で終了します。そのため、購買担当が2件の通知を受け取ることはありません。

「発注を送信者に差戻す」サブプロセスのアクティビティ

ここでは、「発行者への発注差戻」サブプロセスの各アクティビティについて、アクティビティの表示名順に説明します。

開始（ノード1）

これは標準の関数アクティビティで、単にサブプロセスの開始をマークします。

発注ステータスをオリジナル・ステータスに設定（ノード2）

このアクティビティでは、承認者が見つからなければ、発注はこのプロセス・アクティビティに入る前のステータスに設定されます。

承認者が見つからないことを作成者に通知（ノード3）

このアクティビティでは、承認者が見つからなかった場合に、購買担当に通知が送信されます。

この通知のメッセージでは、「文書タイプ」項目属性を使用して2つのPL/SQL関数がコールされます。一方により文書内の明細がすべて取得されて通知に表示され、他方により文書の処理履歴が取得されて通知に表示されます。

送信者は最終承認者ですか?（ノード4）

この関数アクティビティでは、購買担当が単独または最終承認者でもあるかどうかがチェックされます。単独または最終承認者の場合、サブプロセスはノード5をスキップするため、購買担当に2件の通知が送信されることはありません。

最終承認者に承認者が見つからないことを通知（ノード5）

このアクティビティでは、次の承認者が見つからなかったことを示す通知が最終承認者に送信されます。

この通知のメッセージでは、「文書タイプ」項目属性を使用して2つのPL/SQL関数がコールされます。一方により文書内の明細がすべて取得されて通知に表示され、他方により文書の処理履歴が取得されて通知に表示されます。

終了（ノード6）

この関数アクティビティは、プロセスの終了をマークします。アクティビティ自体には結果タイプはありませんが、プロセス内でこのアクティビティの各ノードには処理結果を割り当てる必要があります。処理結果は、アクティビティ・ノードのプロパティ・ページで割り当てます。「発行者への購買依頼差戻」サブプロセス・アクティビティの結果タイプは「発注アクティビティ実行」であるため、各終了アクティビティ・ノードの処理結果は、「発注アクティビティ実行」参照タイプに属する参照コードのいずれか1つと一致する必要があります。

発注否認サブプロセスの概要

発注否認サブプロセスのプロパティを表示するには、対応するプロセス・アクティビティをナビゲータ・ツリーで選択し、「編集」メニューから「プロパティ」を選択します。発注否認サブプロセスの結果タイプは「発注承認処理および文書検証」で、サブプロセスの完了時に結果が「無効な処理」または「有効な処理」となることを示します。この結果は、「発注標準」項目タイプの「発注承認処理および文書検証」参照タイプの参照コードに対応します。

このサブプロセス・アクティビティは実行不可で、最上位レベル・プロセスとしては開始できず、上位レベル・プロセスによりコールされた場合にサブプロセスとしてのみ実行できることを示します。

このサブプロセスはノード1で始まります。

このサブプロセスのノード2では、承認者が発注を否認したことが「処理履歴」ウィンドウに記録され、文書のステータスが「否認済」に変更されます。サブプロセスで文書を否認できない場合（文書のステータスが「消込済」、「凍結済」または「保留中」に変更された場合など）、ノード5で文書を否認できなかったことを示す通知が承認者に送信されます。（文書が否認されると、「発注承認」プロセス内のこのサブプロセスの外側で否認通知が送信されます。）

文書承認処理マネージャがノード2で失敗すると、ノード4で失敗通知が承認者に送信されます。文書承認処理マネージャが正常に再起動された後、承認者またはシステム管理者が通知に「再試行」で応答すると、ワークフローが続行されます。

発注否認サブプロセスのアクティビティ

ここでは、「発注の拒否」サブプロセスの各アクティビティについて、アクティビティの表示名順に説明します。

開始（ノード1）

これは標準の関数アクティビティで、単にサブプロセスの開始をマークします。

発注の否認（ノード2）

この関数アクティビティでは、文書のステータスが「否認済」に更新され、否認が「処理履歴」ウィンドウに記録されます。文書が引当済の場合は、引当も戻し処理されます。

文書を否認できません（ノード5）

このアクティビティでは、Oracle Purchasingが（ステータスが「消込済」、「凍結済」または「保留中」であるなどの原因で）文書を否認できなかったことを示す通知が承認者に送信されます。

文書マネージャ失敗（ノード4）

文書承認処理マネージャが失敗すると、承認者はこの失敗通知を受け取ります。システム管理者が文書承認処理マネージャの再起動に成功した後、承認者はワークフローを続行できるように「再試行」を選択して通知に応答する必要があります。

終了（ノード3および6）

この関数アクティビティは、プロセスの終了をマークします。アクティビティ自体には結果タイプはありませんが、プロセス内でこのアクティビティの各ノードに処理結果を割り当てる必要があります。処理結果は、アクティビティ・ノードのプロパティ・ページで割り当てます。「発注の拒否」サブプロセス・アクティビティの結果タイプは「発注承認処理と文書の検証」であるため、各終了アクティビティ・ノードの処理結果は、「発注承認処理と文書の検証」参照タイプに属する参照コードのいずれか1つと一致する必要があります。

「変更オーダー」プロセスのアクティビティ

関連項目: 変更オーダー承認のワークフロー・プロセス

変更オーダー承認のワークフロー・プロセス

文書を変更したために文書ステータスが「再承認が必要」に変更されると、その文書は変更オーダー・ワークフローへと導かれます。変更オーダー・ワークフローでは、Oracle Purchasingに定義されているのと同じ再承認ルールが使用されます。関連項目: 文書の再承認ルール。

Oracle Purchasingの変更オーダー・ワークフローでは、発注またはリリースについて、手動による再承認を必要とする変更内容（金額、仕入先または日付など）と自動的に再承認される変更内容を定義できます。次の項で説明する変更オーダー・ワークフローを変更する場合、特定の変更について完全な（手動）再承認のバイパスを許可できます。完全または自動的に再承認済の全文書について、文書改訂番号が増分されます。

変更オーダーに関連するワークフロー・プロセスと関数は、いずれも発注承認ワークフローに含まれています。

変更オーダー・ワークフローは、次のすべてに該当する場合に始まります。

• 発注変更により発注のステータスが「再承認が必要」に変わること。

• 発注の文書改訂番号が増分されること。

• 「承認文書」ウィンドウで「承認のために発行」（および「OK」）を選択するか、他の方法で文書を承認のために発行すること。

関連項目

発注承認ワークフロー

変更オーダー・ワークフローのカスタマイズ

ワークフローをカスタマイズするには、Oracle Workflow Builderを使用します。ワークフローをカスタマイズした場合、そのワークフローの影響を受けるのは、カスタマイズ後に承認のために発行される文書のみです。

ワークフロー・モニターを使用すると、ワークフロー・プロセス内の特定の文書の位置をたどることができます。関連項目: 『Oracle Workflowユーザーズ・ガイド』のワークフロー監視の概要に関する項。

Oracle Workflow Builderでワークフローを表示する手順は、次のとおりです。

1. 「ファイル」メニューから「オープン」を選択して、データベースに接続します。

   関連項目: 『Oracle Workflow開発者ガイド』の項目タイプのオープンと保存に関する項

   他のOracle Purchasingワークフローのように、変更オーダー・ワークフローは実際には項目タイプではありませんが、発注承認ワークフローに含まれるプロセスのグループです。したがって、変更オーダー・ワークフローを表示するには、発注承認ワークフローをオープンします。発注承認ワークフローの表示名は「発注承認」で、ワークフロー定義ファイル名はpoxwfpoa.wftです。

   

2. データ・ソースを拡張し、そのデータ・ソース内で「発注承認」項目タイプのブランチを拡張します。

3. 「プロセス」ブランチを拡張し、「発注承認最上位プロセス」アクティビティをダブルクリックします。

   「発注承認最上位プロセス」ダイアグラム内で変更オーダー・プロセスを表示できます。

新規カスタム処理の作成

発注承認ワークフローには変更オーダー・ワークフローのプロセスが含まれており、Oracle Purchasingに用意されているデフォルト・ワークフローを変更するか、デフォルト・ワークフローをコピーして新規ワークフローを作成できます。特定の文書タイプまたは営業単位に使用するカスタムの発注承認ワークフロー起動処理を選択するには、「文書タイプ」ウィンドウを使用します。関連項目: 発注承認ワークフローのカスタマイズ。

重要: 新しい内部名を指定して新規ワークフロー・プロセスを作成すると、将来のアップグレードの実装に影響します。関連項目: アップグレードのサポート。

必要な変更

変更オーダー・ワークフロー自体には、必須の変更はありません。

ただし、変更オーダー・ワークフローを動作させるには、Oracle Purchasingの設定時に選択していない場合は、「文書タイプ」ウィンドウで「アーカイブ時点」に「承認」を選択する必要があります。このオプションを選択すると、発注を承認または再承認するたびに、発注情報がOracle Purchasingのアーカイブ表にコピーされます。変更オーダー・ワークフローでは、このアーカイブ情報を使用して変更前後に文書が比較されます。

サポートされるカスタマイズとサポートされないカスタマイズ

変更オーダー・ワークフローで使用する許容範囲の率を変更して、単価、数量または文書合計について再承認が必要となる引上げ率を決定できます。変更オーダー・ワークフローでは、これらの許容範囲の率がOracle Workflow Builderを使用して変更可能な項目属性として表示されます。たとえば、「変更オーダーの明細の単価の許容範囲」属性の値を0から20に変更できます。これは、単価の引上げまたは引下げが20%未満であれば、文書は完全な再承認プロセスを通過せず、変更オーダー・ワークフローにより自動的に再承認されることを意味します。

次のアクティビティの許容範囲の率を変更できます。

• 変更オーダーのヘッダーの包括購買契約の合計の許容範囲

• 変更オーダーのヘッダーの限度額の許容範囲

• 変更オーダーのヘッダーの発注合計の許容範囲

• 変更オーダーの明細の数量の許容範囲

• 変更オーダーの明細の単価の許容範囲

• 変更オーダーの明細のコミットされた数量の許容範囲

• 変更オーダーの明細の合意金額の許容範囲

• 変更オーダーの明細の限度価格の許容範囲

• 変更オーダーの出荷価格上書きの許容範囲

• 変更オーダーの出荷数量の許容範囲

• 変更オーダーの配分の発注数量の許容範囲

変更オーダー・ワークフローのうち、変更可能なアクティビティと変更不可のアクティビティの詳細は、発注承認ワークフローを参照してください。

カスタマイズの詳細は、この章の「変更オーダー・ワークフロー項目属性」以降の各項を参照してください。これらの項では、発注承認ワークフローの変更オーダー・プロセスのコンポーネントについて説明しています。まだ参照していない場合は、「カスタマイズのガイドライン」も参照してください。

許容範囲の率を変更する手順は、次のとおりです。

1. ワークフロー・ナビゲータで、前述した変更可能な変更オーダー許容範囲項目属性のいずれかを選択します。

2. 項目属性を選択し、「プロパティ」ウィンドウをオープンします。

3. デフォルト値を0から独自の許容範囲値に変更します。

   たとえば、「変更オーダーの明細の単価の許容範囲」属性の値を0から20に変更すると、単価の引上げまたは引下げが20%未満であれば、文書は完全な再承認プロセスを通過せず、変更オーダー・ワークフローにより自動的に再承認されます。

変更オーダー・ワークフロー項目属性

変更オーダー・ワークフローの各プロセスは、「発注承認」項目タイプに関連付けられています。「発注承認」項目タイプの変更オーダー・プロセス・アクティビティは、次のとおりです。

• 文書のすべての変更を取得

• 包括購買契約のすべての変更を取得

• 契約発注のすべての変更を取得

• 計画発注のすべての変更を取得

• リリースのすべての変更を取得

• 標準発注のすべての変更を取得

• 文書の変更に再承認が必要ですか。

• 変更オーダーの承認前予約

• 発注の承認（変更オーダー）

• 文書の印刷（変更オーダー）

• FAX文書 （変更オーダー）

これらのプロセスには多数の属性が関連付けられています。これらの属性は、Oracle Purchasingアプリケーション表の情報を参照します。各属性は、変更オーダー・プロセス全体で関数アクティビティおよび通知アクティビティにより使用され、保守されます。

変更オーダー・ワークフロー項目属性は、「発注承認」項目タイプに関連付けられています。

重要: いずれかの文書明細の項目属性が1つでも許容範囲チェックを通過しない場合は、文書全体が完全な再承認を通過する必要があります。

変更オーダー・ワークフロー: 変更可能な項目タイプ属性

変更オーダー・ワークフロー: 「ヘッダー」項目タイプ属性

変更オーダー・ワークフロー: 「リリース」項目タイプ属性

変更オーダー・ワークフロー: 「明細」項目タイプ属性

変更オーダー・ワークフロー: 「出荷」項目タイプ属性

変更オーダー・ワークフロー: 「配分」項目タイプ属性

「文書のすべての変更を取得」サブプロセスの概要

「文書のすべての変更を取得」サブプロセスのプロパティを表示するには、このプロセスをナビゲータ・ツリーで選択し、「編集」メニューから「プロパティ」を選択します。「文書のすべての変更を取得」サブプロセスの結果タイプは「発注アクティビティ実行」で、プロセスの完了時に結果が「アクティビティが実行されました」となることを示します。この結果は、「発注標準」項目タイプの「発注アクティビティ実行」参照タイプの参照コードに対応します。

このプロセス・アクティビティは実行不可で、最上位レベル・プロセスとしては開始できませんが、上位レベル・プロセスによりコールされた場合にサブプロセスとしてのみ実行できます。

「文書のすべての変更を取得」サブプロセスは、発注承認ワークフローにより文書が新規文書ではなく変更された文書であることと、「文書タイプ」ウィンドウで文書タイプに対して「アーカイブ時点」に「承認」が選択されていることが判別された時点で開始されます。（「アーカイブ時点」に「承認」を選択していないかぎり、変更オーダー・ワークフローは開始されません。関連項目: 変更オーダー・ワークフローのカスタマイズの「必要な変更」。）

このサブプロセスはノード1で始まります。

ノード2では、適切な文書変更収集サブプロセス（ノード3から8まで）が始まるように、文書タイプが判別されます。たとえば、ノード2で文書が契約発注であることが検出されると、ノード3で契約発注の変更内容がすべて検索されます。ノード3からノード8まででは、文書が前回アーカイブ済の改訂と比較され、変更内容が検索されます。

「文書のすべての変更を取得」サブプロセスのアクティビティ

ここでは、「全文書変更の取得」サブプロセスの各アクティビティについて、アクティビティの表示名別に説明します。関数アクティビティによってコールされるPL/SQLストアド・プロシージャを除き、アクティビティのコンポーネントはすべてグラフィカルWorkflow Builderで作成できます。PL/SQLストアド・プロシージャはすべての関数アクティビティで実行されるため、Oracle RDBMS内で作成して格納する必要があります。PL/SQLストアド・プロシージャの命名規則は次のとおりです。

<PACKAGE>.<PROCEDURE> 

<PACKAGE>は全プロシージャをグループ化するパッケージの名称で、<PROCEDURE>はプロシージャ名を表します。

変更オーダー・プロセスで使用されるパッケージとプロシージャの名称を表示するには、各関数アクティビティの「プロパティ」ページを表示します。たとえば、関数アクティビティ「文書タイプを判別」では、<PACKAGE>.<PROCEDURE>名にPO_CHORD_WF0.CHORD_DOC_TYPEが使用されます。

「項目タイプの定義」Webページを使用すると、<PACKAGE>.<PROCEDURE>名を確認できます。関連項目: 『Oracle Workflow開発者ガイド』の「項目タイプの定義」Webページに関する項。

開始（ノード1）

これは標準の関数アクティビティで、単にサブプロセスの開始をマークします。

文書タイプを判別（ノード2）

この関数アクティビティでは、変更済文書の文書タイプが検索されます。

契約発注のすべての変更を取得（ノード3）

関連項目: 契約発注のすべての変更を取得

包括購買契約のすべての変更を取得（ノード4）

関連項目: 包括購買契約のすべての変更を取得

計画発注のすべての変更を取得（ノード5）

関連項目: 計画発注のすべての変更を取得

標準発注のすべての変更を取得（ノード6）

関連項目: 標準発注のすべての変更を取得

リリースのすべての変更を取得（ノード7および8）

ノード7では包括購買リリースのリリース変更がすべて収集され、ノード8では計画リリースのリリース変更がすべて収集されます。関連項目: リリースのすべての変更を取得。

終了（ノード9）

この関数アクティビティは、プロセスの終了をマークします。アクティビティ自体には結果タイプはありませんが、プロセス内でこのアクティビティの各ノードには処理結果を割り当てる必要があります。処理結果は、アクティビティ・ノードのプロパティ・ページで割り当てます。「全文書変更の取得」サブプロセス・アクティビティの結果タイプは「発注アクティビティ実行」であるため、各終了アクティビティ・ノードの処理結果は、「発注アクティビティ実行」参照タイプに属する参照コードのいずれか1つと一致する必要があります。

「包括購買契約のすべての変更を取得」サブプロセスの概要

「包括購買契約のすべての変更を取得」サブプロセスのプロパティを表示するには、このプロセスをナビゲータ・ツリーで選択し、「編集」メニューから「プロパティ」を選択します。「包括購買契約のすべての変更を取得」サブプロセスの結果タイプは「発注アクティビティ実行」で、プロセスの完了時に結果が「アクティビティが実行されました」となることを示します。この結果は、「発注標準」項目タイプの「発注アクティビティ実行」参照タイプの参照コードに対応します。

このプロセス・アクティビティは実行不可で、最上位レベル・プロセスとしては開始できませんが、上位レベル・プロセスによりコールされた場合にサブプロセスとしてのみ実行できます。

このサブプロセスはノード1で始まります。

ノード2および3では、文書が前回アーカイブ済の改訂と比較され、包括購買契約のヘッダーおよび明細の変更がすべて検索されます。このアクティビティにより、適切な項目属性が変更後の値で更新されます。

「包括購買契約のすべての変更を取得」サブプロセスのアクティビティ

ここでは、「包括購買契約のすべての変更を取得」サブプロセスの各アクティビティについて、アクティビティの表示名順に説明します。

開始（ノード1）

これは標準の関数アクティビティで、単にサブプロセスの開始をマークします。

ヘッダーの変更を取得（ノード2）

この関数アクティビティでは、包括購買契約ヘッダーに発生した変更内容がすべて収集され、該当する項目属性が変更内容で更新されます。

明細の変更を取得（ノード3）

この関数アクティビティでは、包括購買契約明細に発生した変更内容がすべて収集され、該当する項目属性が変更内容で更新されます。

終了（ノード4）

この関数アクティビティは、プロセスの終了をマークします。アクティビティ自体には結果タイプはありませんが、プロセス内でこのアクティビティの各ノードには処理結果を割り当てる必要があります。処理結果は、アクティビティ・ノードのプロパティ・ページで割り当てます。「全包括購買契約変更の取得」サブプロセス・アクティビティの結果タイプは「発注アクティビティ実行」であるため、各終了アクティビティ・ノードの処理結果は、「発注アクティビティ実行」参照タイプに属する参照コードのいずれか1つと一致する必要があります。

「契約発注のすべての変更を取得」サブプロセスの概要

「契約発注のすべての変更を取得」サブプロセスのプロパティを表示するには、このプロセスをナビゲータ・ツリーで選択し、「編集」メニューから「プロパティ」を選択します。「契約発注のすべての変更を取得」サブプロセスの結果タイプは「発注アクティビティ実行」で、プロセスの完了時に結果が「アクティビティが実行されました」となることを示します。この結果は、「発注標準」項目タイプの「発注アクティビティ実行」参照タイプの参照コードに対応します。

このプロセス・アクティビティは実行不可で、最上位レベル・プロセスとしては開始できませんが、上位レベル・プロセスによりコールされた場合にサブプロセスとしてのみ実行できます。

このサブプロセスはノード1で始まります。

ノード2では、文書が前にアーカイブ済の改訂と比較され、契約発注の変更内容がすべて検索されます。（契約発注には、ヘッダー情報のみが含まれています。）

「契約発注のすべての変更を取得」サブプロセスのアクティビティ

ここでは、「契約発注のすべての変更を取得」サブプロセスの各アクティビティについて、アクティビティの表示名順に説明します。

開始（ノード1）

これは標準の関数アクティビティで、単にサブプロセスの開始をマークします。

ヘッダーの変更を取得（ノード2）

この関数アクティビティでは、契約発注ヘッダーに発生した変更内容がすべて収集され、該当する項目属性が変更内容で更新されます。

終了（ノード3）

この関数アクティビティは、プロセスの終了をマークします。アクティビティ自体には結果タイプはありませんが、プロセス内でこのアクティビティの各ノードには処理結果を割り当てる必要があります。処理結果は、アクティビティ・ノードのプロパティ・ページで割り当てます。「全契約発注変更の取得」サブプロセス・アクティビティの結果タイプは「発注アクティビティ実行」であるため、各終了アクティビティ・ノードの処理結果は、「発注アクティビティ実行」参照タイプに属する参照コードのいずれか1つと一致する必要があります。

「計画発注のすべての変更を取得」サブプロセスの概要

「計画発注のすべての変更を取得」サブプロセスのプロパティを表示するには、このプロセスをナビゲータ・ツリーで選択し、「編集」メニューから「プロパティ」を選択します。「計画発注のすべての変更を取得」サブプロセスの結果タイプは「発注アクティビティ実行」で、プロセスの完了時に結果が「アクティビティが実行されました」となることを示します。この結果は、「発注標準」項目タイプの「発注アクティビティ実行」参照タイプの参照コードに対応します。

このプロセス・アクティビティは実行不可で、最上位レベル・プロセスとしては開始できませんが、上位レベル・プロセスによりコールされた場合にサブプロセスとしてのみ実行できます。

このサブプロセスはノード1で始まります。

ノード2、3、4および5では、文書が前にアーカイブ済の改訂と比較され、計画発注のヘッダー、明細、出荷および配分の変更内容がすべて検索されます。

「計画発注のすべての変更を取得」サブプロセスのアクティビティ

ここでは、「計画発注のすべての変更を取得」サブプロセスの各アクティビティについて、アクティビティの表示名順に説明します。

開始（ノード1）

これは標準の関数アクティビティで、単にサブプロセスの開始をマークします。

ヘッダーの変更を取得（ノード2）

この関数アクティビティでは、計画発注ヘッダーに発生した変更内容がすべて収集され、該当する項目属性が変更内容で更新されます。

明細の変更を取得（ノード3）

この関数アクティビティでは、計画発注明細に発生した変更内容がすべて収集され、該当する項目属性が変更内容で更新されます。

出荷変更を取得（ノード4）

この関数アクティビティでは、計画発注納入に発生した変更内容がすべて収集され、該当する項目属性が変更内容で更新されます。

配分の変更を取得（ノード5）

この関数アクティビティでは、計画発注配分に発生した変更内容がすべて収集され、該当する項目属性が変更内容で更新されます。

終了（ノード6）

この関数アクティビティは、プロセスの終了をマークします。アクティビティ自体には結果タイプはありませんが、プロセス内でこのアクティビティの各ノードには処理結果を割り当てる必要があります。処理結果は、アクティビティ・ノードのプロパティ・ページで割り当てます。「全計画発注変更の取得」サブプロセス・アクティビティの結果タイプは「発注アクティビティ実行」であるため、各終了アクティビティ・ノードの処理結果は、「発注アクティビティ実行」参照タイプに属する参照コードのいずれか1つと一致する必要があります。

「リリースのすべての変更を取得」サブプロセスの概要

「リリースのすべての変更を取得」サブプロセスのプロパティを表示するには、このプロセスをナビゲータ・ツリーで選択し、「編集」メニューから「プロパティ」を選択します。「リリースのすべての変更を取得」サブプロセスの結果タイプは「発注アクティビティ実行」で、プロセスの完了時に結果が「アクティビティが実行されました」となることを示します。この結果は、「発注標準」項目タイプの「発注アクティビティ実行」参照タイプの参照コードに対応します。

このプロセス・アクティビティは実行不可で、最上位レベル・プロセスとしては開始できませんが、上位レベル・プロセスによりコールされた場合にサブプロセスとしてのみ実行できます。

このサブプロセスはノード1で始まります。

ノード 2、3および4では、文書が前にアーカイブ済の改訂と比較され、包括購買リリースまたは計画リリースのヘッダー、納入および配分の変更内容がすべて検索されます。

「リリースのすべての変更を取得」サブプロセスのアクティビティ

ここでは、「全リリース変更の取得」サブプロセスの各アクティビティについて、アクティビティの表示名順に説明します。

開始（ノード1）

これは標準の関数アクティビティで、単にサブプロセスの開始をマークします。

リリースの変更を取得（ノード2）

この関数アクティビティでは、リリース・ヘッダーに発生した変更内容がすべて収集され、該当する項目属性が変更内容で更新されます。

出荷変更を取得（ノード3）

この関数アクティビティでは、リリース納入に発生した変更内容がすべて収集され、該当する項目属性が変更内容で更新されます。

配分の変更を取得（ノード4）

この関数アクティビティでは、リリース配分に発生した変更内容がすべて収集され、該当する項目属性が変更内容で更新されます。

終了（ノード5）

この関数アクティビティは、プロセスの終了をマークします。アクティビティ自体には結果タイプはありませんが、プロセス内でこのアクティビティの各ノードには処理結果を割り当てる必要があります。処理結果は、アクティビティ・ノードのプロパティ・ページで割り当てます。「全リリース変更の取得」サブプロセス・アクティビティの結果タイプは「発注アクティビティ実行」であるため、各終了アクティビティ・ノードの処理結果は、「発注アクティビティ実行」参照タイプに属する参照コードのいずれか1つと一致する必要があります。

「標準発注のすべての変更を取得」サブプロセスの概要

「標準発注のすべての変更を取得」サブプロセスのプロパティを表示するには、このプロセスをナビゲータ・ツリーで選択し、「編集」メニューから「プロパティ」を選択します。「標準発注のすべての変更を取得」サブプロセスの結果タイプは「発注アクティビティ実行」で、プロセスの完了時に結果が「アクティビティが実行されました」となることを示します。この結果は、「発注標準」項目タイプの「発注アクティビティ実行」参照タイプの参照コードに対応します。

このプロセス・アクティビティは実行不可で、最上位レベル・プロセスとしては開始できませんが、上位レベル・プロセスによりコールされた場合にサブプロセスとしてのみ実行できます。

このサブプロセスはノード1で始まります。

ノード2、3、4および5では、文書が前にアーカイブ済の改訂と比較され、標準発注のヘッダー、明細、納入および配分の変更内容がすべて検索されます。

「標準発注のすべての変更を取得」サブプロセスのアクティビティ

ここでは、「標準発注のすべての変更を取得」サブプロセスの各アクティビティについて、アクティビティの表示名順に説明します。

開始（ノード1）

これは標準の関数アクティビティで、単にサブプロセスの開始をマークします。

ヘッダーの変更を取得（ノード2）

この関数アクティビティでは、標準発注ヘッダーに発生した変更内容がすべて収集され、該当する項目属性が変更内容で更新されます。

明細の変更を取得（ノード3）

この関数アクティビティでは、標準発注明細に発生した変更内容がすべて収集され、該当する項目属性が変更内容で更新されます。

出荷変更を取得（ノード4）

この関数アクティビティでは、標準発注納入に発生した変更内容がすべて収集され、該当する項目属性が変更内容で更新されます。

配分の変更を取得（ノード5）

この関数アクティビティでは、標準発注配分に発生した変更内容がすべて収集され、該当する項目属性が変更内容で更新されます。

終了（ノード6）

この関数アクティビティは、プロセスの終了をマークします。アクティビティ自体には結果タイプはありませんが、プロセス内でこのアクティビティの各ノードには処理結果を割り当てる必要があります。処理結果は、アクティビティ・ノードのプロパティ・ページで割り当てます。「全標準発注変更の取得」サブプロセス・アクティビティの結果タイプは「発注アクティビティ実行」であるため、各終了アクティビティ・ノードの処理結果は、「発注アクティビティ実行」参照タイプに属する参照コードのいずれか1つと一致する必要があります。

「文書の変更に再承認が必要ですか。」サブプロセスの概要

「文書の変更に再承認が必要ですか。」サブプロセスのプロパティを表示するには、このプロセスをナビゲータ・ツリーで選択し、「編集」メニューから「プロパティ」を選択します。「文書の変更に再承認が必要ですか。」サブプロセスの結果タイプは「Yes/No」で、プロセスの完了時に結果が「Yes」または「No」となることを示します。この結果は、「標準」項目タイプの「Yes/No」参照タイプの参照コードに対応します。

このプロセス・アクティビティは実行不可で、最上位レベル・プロセスとしては開始できませんが、上位レベル・プロセスによりコールされた場合にサブプロセスとしてのみ実行できます。

このサブプロセスはノード1で始まります。

ノード2では文書タイプが判別されます。ノード3から8では、文書の要素が変更されたために文書が完全な承認プロセス（承認階層内で次の承認者を検索し、通知を送信するなど）の通過を必要とするか、または即時に承認されるかが判別されます。変更があった要素に承認が必要な場合は、「発注承認」プロセスが（このサブプロセスの外側の発注承認ワークフロー全体で）始まります。

たとえば、ノード2で文書が包括購買契約であることが検出されると、ノード3では基本契約の変更内容に完全な再承認が必要かどうかがチェックされます。ノード4では、契約発注に対して同様のチェックが実行されます。

「文書の変更に再承認が必要ですか。」サブプロセスでは、Oracle Purchasingで定義済の再承認ルール（または、変更オーダー許容範囲属性を変更した場合はその属性）を使用して、文書が完全な承認プロセスの通過を必要とするかどうかが判別されます。

「文書の変更に再承認が必要ですか。」サブプロセスのアクティビティ

ここでは、「文書の変更に再承認が必要ですか。」サブプロセスの各アクティビティについて、アクティビティの表示名順に説明します。

開始（ノード1）

これは標準の関数アクティビティで、単にサブプロセスの開始をマークします。

文書タイプを判別（ノード2）

この関数アクティビティでは、変更済文書の文書タイプが検索されます。

包括購買契約に再承認は必要ですか?（ノード3）

この関数アクティビティでは、包括購買契約が承認プロセスの通過を必要とする場合は値「Yes」、必要としない場合は「No」が戻されます。このサブプロセスでは、Oracle Purchasingで定義済の再承認ルール（または、変更オーダー許容範囲属性を変更した場合はその属性）を使用して、文書が完全な「発注承認」プロセスの通過を必要とするか、または即時に承認可能であるかが判別されます。

契約発注に再承認は必要ですか?（ノード4）

この関数アクティビティでは、ノード3と同じアクティビティが契約発注に対して実行されます。

計画発注に再承認は必要ですか?（ノード5）

この関数アクティビティでは、ノード3と同じアクティビティが計画発注に対して実行されます。

計画リリースに再承認は必要ですか?（ノード8）

この関数アクティビティでは、ノード3と同じアクティビティが計画リリースに対して実行されます。

標準発注に再承認は必要ですか?（ノード6）

この関数アクティビティでは、ノード3と同じアクティビティが標準発注に対して実行されます。

包括購買リリースに再承認は必要ですか?（ノード7）

この関数アクティビティでは、ノード3と同じアクティビティが包括購買リリースに対して実行されます。

終了（ノード9、10、11、12、13、14、15、16、17、18、19および20）

この関数アクティビティは、プロセスの終了をマークします。アクティビティ自体には結果タイプはありませんが、プロセス内でこのアクティビティの各ノードには処理結果を割り当てる必要があります。処理結果は、アクティビティ・ノードのプロパティ・ページで割り当てます。「文書変更に再承認が必要ですか?」サブプロセス・アクティビティの結果タイプは「発注アクティビティ実行」であるため、各終了アクティビティ・ノードの処理結果は、「発注アクティビティ実行」参照タイプに属する参照コードのいずれか1つと一致する必要があります。

「変更オーダーの承認前予約」サブプロセスの概要

「変更オーダーの承認前予約」サブプロセスのプロパティを表示するには、このプロセスをナビゲータ・ツリーで選択し、「編集」メニューから「プロパティ」を選択します。「変更オーダーの承認前予約」サブプロセスの結果タイプは「Yes/No」で、プロセスの完了時に結果が「Yes」または「No」となることを示します。この結果は、「標準」項目タイプの「Yes/No」参照タイプの参照コードに対応します。

このプロセス・アクティビティは実行不可で、最上位レベル・プロセスとしては開始できませんが、上位レベル・プロセスによりコールされた場合にサブプロセスとしてのみ実行できます。

このサブプロセスはノード1で始まります。

ノード2で引当が有効で予算が予約されていないことが検出されると、ノード4で文書に対する予算の予約が試行されます。

予算を予約できなければ、ノード6で承認者に「文書を予約できません」という通知が送信されます。承認者は、より多くの予算が割当済だった場合などは、「承認文書」ウィンドウを使用して文書の予約を再試行してから、通知に「再試行」で応答するか、文書を否認するか、または予算予約のために承認権限を持つ他の承認者に文書を転送する必要があります。

承認者が文書を転送すると、ノード7で転送先承認者が有効なユーザー名を持っているかどうかがチェックされます。有効なユーザー名を持っている場合は、ノード8で新規承認者の転送先/転送元情報が設定されます。

承認者が文書を否認すると、ノード9で発注が否認されます。発注を（ステータスが「消込済」、「凍結済」または「保留中」であるなど、文書がステータス・チェックに失敗したことが原因で）否認できない場合、文書を否認できなかったことを示す通知がノード11で承認者に送信されます。

文書承認処理マネージャがノード4または9で失敗すると、ノード5または10の通知アクティビティにより失敗通知が承認者に送信され、承認者またはシステム管理者が通知に「再試行」で応答すると、ワークフローが続行されます。

「変更オーダーの承認前予約」サブプロセスのアクティビティ

ここでは、「変更オーダーの承認前予約」サブプロセスの各アクティビティについて、アクティビティの表示名順に説明します。

開始（ノード1）

これは標準の関数アクティビティで、単にサブプロセスの開始をマークします。

予算引当がオンで文書は未予約ですか?（ノード2）

この関数アクティビティでは、予算引当会計を使用しているかどうかと、文書が予約済かどうかが判別されます。

文書を予約（ノード4）

この関数アクティビティでは、文書に対する予算の予約が試行されます。

文書マネージャ失敗（ノード5および10）

文書マネージャが失敗すると、承認者は必ず失敗通知を受け取ります。システム管理者が文書承認処理マネージャの再起動に成功した後、承認者はワークフローを続行できるように「再試行」を選択して通知に応答する必要があります。

文書を予約できません（ノード6）

このアクティビティでは、Oracle Purchasingが文書に対する予算の予約に失敗したことが文書所有者に通知され、問題解決に関する指示が提供されます。

転送先は有効ですか?（ノード7）

この関数アクティビティでは、承認通知への応答の「転送先」フィールドに入力された転送先名が有効なユーザー名かどうかがチェックされます。

転送処理の転送先と転送元を設定（ノード8）

この関数アクティビティでは、「転送」処理の後に「転送先」および「転送元」属性が再設定されます。

発注の否認（ノード9）

この関数アクティビティでは、否認された発注が「否認済」ステータスに設定され、「処理履歴」ウィンドウ内で否認が記録されます。文書が引当済の場合は、引当も戻し処理されます。

文書を否認できません（ノード11）

このアクティビティでは、Oracle Purchasingが文書を正常に否認できなかったことを示す通知が文書所有者に送信されます。

終了（ノード3および12）

この関数アクティビティは、プロセスの終了をマークします。アクティビティ自体には結果タイプはありませんが、プロセス内でこのアクティビティの各ノードには処理結果を割り当てる必要があります。処理結果は、アクティビティ・ノードのプロパティ・ページで割り当てます。「変更オーダーの承認前予約」サブプロセス・アクティビティの結果タイプは「Yes/No」であるため、各終了アクティビティ・ノードの処理結果は、「Yes/No」参照タイプに属する参照コードのいずれか1つと一致する必要があります。

「発注の承認（変更オーダー）」サブプロセスの概要

「発注の承認（変更オーダー）」サブプロセスのプロパティを表示するには、対応するプロセス・アクティビティをナビゲータ・ツリーで選択し、「編集」メニューから「プロパティ」を選択します。「発注の承認（変更オーダー）」サブプロセスの結果タイプは「発注承認処理および文書検証」で、サブプロセスの完了時に結果が「無効な処理」または「有効な処理」となることを示します。この結果は、「発注標準」項目タイプの「発注承認処理および文書検証」参照タイプの参照コードに対応します。

このサブプロセス・アクティビティは実行不可で、最上位レベル・プロセスとしては開始できず、上位レベル・プロセスによりコールされた場合にサブプロセスとしてのみ実行できることを示します。

発注変更が完全な再承認を必要とする場合は、このプロセスにより発注が承認されます。発注の承認中に検証に失敗すると、このプロセスにより、文書がステータス・チェックまたは正誤チェックに失敗したことを示す通知が購買担当に送信されます。

このサブプロセスはノード1で始まります。

ノード2では、文書が（「承認前に予約」サブプロセスなどで）承認済かどうかがチェックされます。承認済の場合、このサブプロセスはノード3で終了し、文書が承認済であることを示す通知がワークフローにより（「発注承認」プロセス内で）購買担当に送信されます。

承認済でない場合は、文書の承認準備が完了しているかどうかがノード4で検証されます。承認準備が完了していない場合は、文書がステータス・チェックに失敗したこと（文書のステータスが「消込済」、「凍結済」または「保留中」に変更されたなど）を示す通知が、ノード5で承認者に送信されます。その後、ノード6で発注はこのサブプロセスに入る前のステータスに戻され、ワークフローはノード7で終了します。発注を変更して再発行するか、新規発注を作成する場合は、発注を承認のために発行する時点で発注承認ワークフローが開始されます。

文書がステータス・チェックを通過すると、ノード8では文書が完了しているかどうかが検証されます（明細と配分がそれぞれ1つ以上含まれているかどうかの確認など）。 文書が完了していなければ、ノード10でその旨を示す通知が承認者に送信されます。承認者は、「再試行」を選択して通知に応答するか（システム・レベルの問題がある場合に役立ちます）、または文書を否認できます。ノード13で文書を否認できない場合（文書のステータスが「消込済」、「凍結済」または「保留中」に変更されたなど）、ノード14で文書所有者に「文書を否認できません」という通知が送信されます。

文書がステータス・チェックを通過し、完了している場合は、ノード17で文書が承認され、発注情報と他の内部ワークフロー属性に変更があった場合は、ノード19でこれらの情報が取得されます。

文書承認処理マネージャがノード4、8、13または17で失敗すると、ノード9、11、12または18の通知アクティビティにより失敗通知が承認者に送信されます。文書承認処理マネージャが正常に再起動された後、承認者またはシステム管理者が通知に「再試行」で応答すると、ワークフローが続行されます。

関連項目: 文書ステータス・チェック、関連項目: 文書実行チェック

「発注の承認（変更オーダー）」サブプロセスのアクティビティ

ここでは、「発注の承認」サブプロセスの各アクティビティについて、アクティビティの表示名順に説明します。

開始（ノード1）

これは標準の関数アクティビティで、単にサブプロセスの開始をマークします。

文書は承認されていますか?（ノード2）

予算引当を使用しており、予算が予約された時点で文書が「事前承認済」だった場合、そのステータスはすでに「承認済」に変更されています。

文書ステータスは承認を許可しますか?（ノード4）

承認処理を許可する文書ステータスの例は、「未完了」、「処理中」および「事前承認済」です。

文書は完了していますか?（ノード8）

この関数アクティビティでは、文書が完了しているかどうか（すべての数量が一致し、明細と配分がそれぞれ1つ以上存在するかどうかなど）が検証されます。

発注を承認（ノード17）

このアクティビティでは、発注のステータスが「承認済」に設定されます。

発注属性を取得（ノード19）

この関数アクティビティでは、発注ヘッダーおよび明細のキー値に変更があった場合に、これらの値が取得され、ワークフロー属性に割り当てられます。

文書マネージャ失敗（ノード9、11、12および18）

文書承認処理マネージャが失敗すると、承認者はこの失敗通知を受け取ります。システム管理者が文書承認処理マネージャの再起動に成功した後、承認者はワークフローを続行できるように「再試行」を選択して通知に応答する必要があります。

文書のステータス・チェック失敗（ノード5）

このアクティビティでは、文書のステータス・チェックに失敗したことを示す通知が承認者に送信されます。関連項目: 文書ステータス・チェック。

発注ステータスをオリジナル・ステータスに設定（ノード6）

文書がステータス・チェックに失敗すると、この関数アクティビティでは、発注がこのプロセス・アクティビティに入る前のステータスに設定されます。

承認できません（ノード10）

このアクティビティでは、Oracle Purchasingが文書を承認できなかったことを示す通知が承認者に送信されます。

発注の否認（ノード13）

この関数アクティビティでは、文書のステータスが「否認済」に更新され、否認が「処理履歴」ウィンドウに記録されます。

文書を否認できません（ノード14）

このアクティビティでは、Oracle Purchasingが（ステータスが「消込済」、「凍結済」または「保留中」であるなどの原因で）文書を否認できなかったことを示す通知が承認者に送信されます。

終了（ノード3、7、15および16）

この関数アクティビティは、プロセスの終了をマークします。アクティビティ自体には結果タイプはありませんが、プロセス内でこのアクティビティの各ノードに処理結果を割り当てる必要があります。処理結果は、アクティビティ・ノードのプロパティ・ページで割り当てます。「発注の承認（変更オーダー）」サブプロセス・アクティビティの結果タイプは「発注承認処理と文書の検証」であるため、各終了アクティビティ・ノードの処理結果は、「発注承認処理と文書の検証」参照タイプに属する参照コードのいずれか1つと一致する必要があります。

文書の印刷プロセス（変更オーダー）およびFAX文書プロセス （変更オーダー）の概要

文書の印刷プロセス（変更オーダー）またはFAX文書プロセス （変更オーダー）のプロパティを表示するには、対応するプロセス・アクティビティをナビゲータ・ツリーで選択し、「編集」メニューから「プロパティ」を選択します。このサブプロセスの結果タイプは「発注アクティビティ実行」で、サブプロセスの完了時に結果が「アクティビティが実行されました」となることを示します。この結果は、「発注標準」項目タイプの「発注アクティビティ実行」参照タイプの参照コードに対応します。

文書の印刷プロセス（変更オーダー）

このサブプロセスはノード1で始まります。

ノード2では、発注が承認のために初めて発行されたときに「承認文書」ウィンドウで「印刷」が選択されたかどうかがチェックされます。「印刷」が選択された場合は、ノード4で文書が印刷されます。

FAX文書プロセス （変更オーダー）

FAX文書プロセス （変更オーダー）の外観と動作は文書の印刷プロセス（変更オーダー）と同様ですが、ノード2では「承認文書」ウィンドウで「FAX」が選択されたかどうかがチェックされます。「FAX」が選択された場合、「承認文書」ウィンドウでFAX番号が入力されていれば、ノード4で自動的に文書がFAX送信されます。（FAX番号が指定されていなければ、文書は承認後にFAXサーバーに送信されます。CommercePathの設定に応じて、FAXサーバーに格納された文書の送信先と送信時期を選択できます。）

FAX機能を使用するには、CommercePath、またはCommercePath Fax Command Language（FCL）を使用するFAXソフトウェアをインストールする必要があります。

文書の印刷プロセス（変更オーダー）およびFAX文書プロセス （変更オーダー）のアクティビティ

ここでは、「文書の印刷（変更オーダー）」および「FAX文書（変更オーダー）」サブプロセスの各アクティビティについて、アクティビティの表示名順に説明します。

開始（ノード1）

これは標準の関数アクティビティで、単にサブプロセスの開始をマークします。

ユーザーは文書印刷を希望していますか?（ノード2）

この関数アクティビティでは、発注の初回発行時に「承認文書」ウィンドウで「印刷」が選択されたかどうかがチェックされます。

「FAX文書」プロセスの場合、「ユーザーは文書のFAXを希望するか?」関数アクティビティにより、「承認文書」ウィンドウで「FAX」が選択されたかどうかがチェックされます。FAX機能を使用するには、CommercePath、またはCommercePath Fax Command Language（FCL）を使用するFAXソフトウェアをインストールする必要があります。

印刷文書（ノード4）

発注の初回発行時に「承認文書」ウィンドウで「印刷」が選択された場合は、このアクティビティにより文書が印刷されます。

「FAX文書」プロセスの場合、「承認文書」ウィンドウでFAX番号が入力されていれば、「FAX文書」関数アクティビティにより文書が自動的にFAX送信されます。FAX機能を使用するには、CommercePath、またはCommercePath Fax Command Language（FCL）を使用するFAXソフトウェアをインストールする必要があります。

終了（ノード3および5）

この関数アクティビティは、プロセスの終了をマークします。アクティビティ自体には結果タイプはありませんが、プロセス内でこのアクティビティの各ノードには処理結果を割り当てる必要があります。処理結果は、アクティビティ・ノードのプロパティ・ページで割り当てます。「文書の印刷（変更オーダー）」サブプロセス・アクティビティの結果タイプは「発注アクティビティ実行」であるため、各終了アクティビティ・ノードの処理結果は、「発注アクティビティ実行」参照タイプに属する参照コードのいずれか1つと一致する必要があります。

「発注およびリリースの作成」ワークフロー

Oracle PurchasingはOracle Workflowテクノロジと統合されており、承認済購買依頼明細から自動的に標準発注または包括購買リリースが作成されます。購買文書を自動的に作成するためのワークフローは、「発注文書の作成」と呼ばれます。このワークフローをOracle Workflow Builderで変更して、承認済購買依頼を標準発注および包括購買リリースに自動的に変換する時期を決定するビジネス・ルールを追加定義できます。

Oracle Workflow Builderでは、「発注文書の作成」は複数のプロセスで構成されています。これらの各プロセスはOracle Workflow Builderでダイアグラムとして参照し、そのオブジェクトとプロパティを変更できます。各ワークフロー・プロセスは個別関数で構成されています。

自動承認を許可している場合、発注文書の作成ワークフローで正常に作成された文書ごとに、文章を承認するための発注承認ワークフローがコールされます。関連項目: 文書作成オプションの選択。関連項目: 発注承認ワークフロー。

発注文書の作成ワークフローは、承認済購買依頼明細に対する購買依頼承認ワークフローの終了時に開始されます。このワークフローでは、「自動作成は許可されていますか?」項目属性を「Y」（Yes）に設定したままの場合、ソース文書が購買依頼明細に関連付けられている場合、およびソース・ルールを適切に設定している場合（関連項目: 自動ソースの設定）、自動文書作成が開始されます。購買依頼明細に関連付けられているソース文書が見積の場合は、標準発注が作成されます。ソース文書が包括購買契約の場合は、リリースが作成されます。

発注およびリリースに対する変更を承認するためのワークフロー・プロセスもあります。関連項目: 変更オーダー承認のワークフロー・プロセス。

自動文書作成ワークフローのカスタマイズ

ワークフローをカスタマイズするには、Oracle Workflow Builderを使用します。ワークフローをカスタマイズした場合、そのワークフローの影響を受けるのは、カスタマイズ後に作成する文書のみです。

Oracle Workflow Builderを使用して、組織内の文書タイプごとに一意の文書作成ワークフローを作成することもできます。「文書タイプ」ウィンドウで、特定のワークフローを特定の文書タイプに関連付けます。関連項目: 文書タイプの定義。

ワークフロー・モニターを使用すると、ワークフロー・プロセス内の特定の文書の位置をたどることができます。関連項目: 『Oracle Workflowユーザーズ・ガイド』のワークフロー監視の概要に関する項。

Oracle Workflow Builderでワークフローを表示する手順は、次のとおりです。

1. 「ファイル」メニューから「オープン」を選択して、データベースに接続します。

   関連項目: 『Oracle Workflow開発者ガイド』の項目タイプのオープンと保存に関する項

   自動文書作成ワークフローの表示名は「発注文書の作成」です。ワークフロー定義ファイル名はpoxwfatc.wftです。

   

2. データ・ソースを拡張し、そのデータ・ソース内で「発注文書の作成」項目タイプのブランチを拡張します。

3. 「プロセス」ブランチを拡張し、プロセス・アクティビティをダブルクリックしてダイアグラムを表示します。

新規カスタム処理の作成

Oracle Purchasingに用意されているデフォルトの発注文書の作成ワークフローを変更する方法と、それをコピーして新規ワークフローを作成する方法があります。「文書タイプ」ウィンドウを使用して、特定の文書タイプまたは営業単位用にカスタムのワークフロー起動処理を選択できます。

文書や営業単位ごとに異なるワークフローを作成する場合は、項目タイプをコピーして名称変更するのではなく（発注文書の作成1など）、「ワークフロー起動処理」をコピーして名称変更し、独自のカスタム・サブプロセスをコールするように変更することをお薦めします。全営業単位が同じ項目タイプを指し、その項目タイプに必要なデフォルトの項目属性と他のアクティビティを使用するようになりますが、営業単位の1つもカスタム起動処理を使用することになります。

重要: 新しい内部名を指定して新規ワークフロー・プロセスを作成すると、将来のアップグレードの実装に影響します。関連項目: アップグレードのサポート。

必要な変更

発注文書の作成ワークフローに必須の変更はありません。ただし、この項ではOracle Purchasingの設定を完了し、「ワークフロー・オプションの選択」で説明したOracle Workflow設定ステップを実行していることを前提としています。

サポートされるカスタマイズとサポートされないカスタマイズ

この項では、発注文書の作成ワークフローについて、変更可能な内容と変更不可の内容を説明します。変更可能な内容については、カスタマイズする際に注意を必要とする重要なガイドラインについても説明します。

ワークフローのカスタマイズ方法に関する重要情報は、『Oracle Workflow開発者ガイド』を参照してください。

カスタマイズの詳細は、この章の「「発注文書の作成」ワークフロー項目属性」以降の各項を参照してください。これらの項では、発注文書の作成ワークフローの自動文書作成プロセスのコンポーネントについて説明しています。まだ参照していない場合は、「カスタマイズのガイドライン」も参照してください。

重要: 以降の各項で、特定のワークフロー・オブジェクトがカスタマイズ可能オブジェクトのリストに記載されていない場合は、アクセス・レベルに関係なく変更しないでください。

属性

変更できるのは次の属性のみで、デフォルト値を変更します。

• 自動作成は許可されていますか?

• 自動承認は許可されていますか?

• ワークフローでリリースを作成しますか?

これらの項目属性のデフォルト値の変更方法は、「文書作成オプションの選択」を参照してください。

プロセス

プロセスを変更する場合は、データベース内のデータの整合性を維持するために基本的なフローをそのまま保つことが重要です。たとえば、「購買依頼明細情報を検証」プロセスの「購買依頼明細情報を取得」関数アクティビティでは、多数の項目属性が購買依頼明細情報で更新されます。次に、これらの項目属性により、該当情報がワークフロー内の他の関数アクティビティおよびプロセスに渡されます。したがって、この関数アクティビティを削除またはバイパスしないでください。この関数アクティビティを独自の関数アクティビティに置き換える場合も、これらの項目属性が設定されることを確認する必要があります。ただし、「購買依頼明細情報を検証」プロセスに付加的なチェック（プロセスまたは関数アクティビティ）を追加することはできます。

プロセスを変更するには、そのフローの一部を置き換える方法と、新しい関数アクティビティを追加する方法があります。どちらの場合も、次のことに注意してください。

• デフォルト・プロセスのデフォルト関数アクティビティによって設定される属性は、デフォルト関数アクティビティを独自のものに置き換えた場合も設定される必要があります。つまり、そのプロセス内の関数アクティビティがSetItemAttr文を使用している場合、その関数アクティビティは後で他の関数アクティビティに使用される属性を設定します。したがって、新しい関数アクティビティも同じ属性を設定する必要があります。また、 SetItemUserKey文およびSetItemOwner文があれば、それも保存する必要があります。カスタマイズの内容によっては、GetItemAttr文も保存してください。

• デフォルト・プロセスが保守しているデータベースの状態は、カスタマイズしたプロセスでも保守する必要があります。つまり、カスタマイズしたプロセスの関数アクティビティでUpdate文またはInsert Into文を使用する場合、その関数アクティビティは、データベースの行を更新または挿入します。したがって、新規の関数アクティビティは、データベースを同じ状態に保守する必要があります。

  SetItemAttr文、GetItemAttr文、SetItemUserKey文、SetItemOwner文、Insert Into文またはUpdate文を使用するワークフロー関数アクティビティのリストを取得するには、PL/SQLスクリプトpowfcustを実行します。このスクリプトの実行手順は、「カスタマイズのガイドライン」を参照してください。

「発注文書の作成」のプロセスはすべて変更可能ですが、個別に後述する情報を慎重に検討してください。

文書作成全体/承認の起動

「文書作成全体/承認の起動」プロセスの場合、「自動作成は許可されていますか?」関数アクティビティを独自の関数アクティビティに置き換えることができます。この関数アクティビティでは、同じ名称の項目属性が検索され、承認済購買依頼からの自動文書作成が許可されているかどうかが確認されます。ただし、この関数アクティビティは、より複雑なロジックを持つ独自の関数アクティビティに置き換えることができます。たとえば、特定の合計価格を下回る購買依頼について自動文書作成を許可する関数アクティビティに置き換えることができます。

通知アクティビティを（「発注またはリリースの作成/承認プロセスを起動」の後などに）追加して、ワークフローが発注を作成して承認しようとしていることを購買担当に知らせることもできます。

このような追加を除き、「文書作成全体/承認の起動」プロセスの基本的なフローに他の関数アクティビティの追加や削除を割り込ませないでください。

発注またはリリースを作成して承認

「文書作成全体/承認の起動」プロセスの「自動作成は許可されていますか?」と同様に、「自動承認は許可されていますか?」関数アクティビティを、特定の種類の文書についてのみ自動承認を許可する独自の関数アクティビティに置き換えることができます。たとえば、一定の合計価格を下回る発注を自動的に承認できます。

購買担当者を取得

「購買担当者を取得」プロセスは、前のどのアクティビティでも購買担当が見つからなければ常に特定の購買担当を使用するように、最後の関数アクティビティを追加することで変更できます。または、これらの関数アクティビティすべてを、単に購買担当負荷を使用して発注またはリリースに使用する購買担当を判別する1つ以上の独自関数アクティビティに置き換えることもできます。

文書の自動作成に必要な情報が購買依頼明細にありますか?

このプロセス内の関数アクティビティを独自の関数アクティビティに置き換えることはお薦めしません。

たとえば、発注またはリリースを作成するには仕入先が必須です。したがって、「購買依頼明細に有効な仕入先情報がありますか?」関数アクティビティは他の関数アクティビティに置き換えないでください。また、この関数アクティビティから収集された情報は、後で必須の仕入先および価格設定情報を取得する関数アクティビティ（「発注またはリリースの作成/承認プロセスを起動」および「ソース文書タイプを取得」など）で使用されます。

同様に、「REQ 明細に有効なソース文書情報はありますか。」関数アクティビティを介してソース文書情報を収集しないと、「購買依頼明細情報を検証」サブプロセスの多数の関数アクティビティを完了できません。

「文書の自動置換作成に必要な情報が購買依頼明細にありますか?」関数アクティビティを置き換えることはお薦めしませんが、このサブプロセスに関数アクティビティ（付加的な情報チェックなど）を追加することは可能です。

購買依頼明細情報を検証

「購買依頼明細情報を検証」サブプロセスの場合、「ワークフローでリリースを作成しますか?」関数アクティビティにより同じ名称の項目属性が検索され、項目属性が「Y」（Yes）と「N」（No）のどちらに設定されているかが確認されます。（この属性はユーザーが「Y」または「N」に設定できます。関連項目: 文書作成オプションの選択。デフォルトは「Y」で、ワークフローではリリースが作成されます。）「ワークフローでリリースを作成しますか?」関数アクティビティでは、対応する項目属性が検索されて、ワークフローでリリースを作成するか、ユーザーが「文書の自動作成」ウィンドウを介してリリースを作成する必要があるかが判別されます。

「ワークフローでリリースを作成しますか?」関数アクティビティは、ワークフローでリリースを作成する必要があるかどうかの判別に異なるロジック（Yes/No以外）を使用する独自の関数アクティビティに、置き換えることができます。購買依頼の価格設定または仕入先情報を検索して、リリースを作成するかどうかを判別する関数アクティビティを作成できます。たとえば、ワークフローでは、特定の仕入先についてのみリリースを自動作成し、他の仕入先については自動ではなく、ユーザーが「自動作成」を使用してリリースを作成することもできます。

通知

発注文書の作成ワークフローでは、ビジネス・ニーズに応じて次の通知を変更できます。

• 発注またはリリースが作成された

関連項目: 『Oracle Workflow開発者ガイド』の通知アクティビティの作成に関する項。関連項目: 『Oracle Workflow開発者ガイド』のメッセージ結果に関する項。関連項目: 『Oracle Workflow開発者ガイド』のメッセージの作成に関する項。

関数アクティビティ

発注文書の作成ワークフローの関数アクティビティは変更できません。

ただし、一部の関数アクティビティは、独自の関数アクティビティに置き換えることができます。関数アクティビティを置き換える場合は、それを含んでいるプロセスを変更します。関連項目: 前述の「プロセス」の「発注文書の作成」プロセスのカスタマイズのガイドライン。

プロセスのデフォルト関数アクティビティを独自作成した関数アクティビティに置き換える場合は、次の点に注意する必要があります。

• 新しい関数アクティビティの結果タイプは、デフォルト・アクティビティの結果タイプと一致する必要があります。つまり、Oracle Workflow Builderにおける関数アクティビティの「結果タイプ」は、その関数アクティビティの対応するPL/SQLプロシージャで指定する結果タイプと一致する必要があります（「Yes/No」結果タイプなど）。また、関数アクティビティおよび対応するPL/SQLプロシージャに2つの結果（「Yes」と「No」など）がある場合は、ワークフロー・ダイアグラム内に2つの対応する遷移が（「Yes」に1つと「No」に1つ）存在することも確認してください。プロセスの結果タイプと遷移を変更する場合は、特別な遷移やチェックを削除またはバイパスしないように注意する必要があります。

• 前述の「プロセス」と同様に、デフォルト関数アクティビティにより設定されていた属性は、カスタマイズした関数アクティビティでも設定する必要があります。

• 前述の「プロセス」と同様に、デフォルト関数アクティビティにより維持されていたデータベースの状態は、カスタマイズした関数アクティビティでも維持する必要があります。

メッセージ

発注文書の作成ワークフローの場合、次のメッセージのメッセージ本文を変更できます。

• 発注文書が作成された

参照タイプ

発注文書の作成ワークフローの参照タイプは変更できません。

「発注文書の作成」項目タイプ

自動文書作成プロセスは、「発注文書の作成」という項目タイプに関連付けられています。この項目タイプにより、発注とリリースの自動作成に使用可能なワークフロー・プロセスがすべて識別されます。「発注文書の作成」に関連付けられているワークフロー・プロセスは、次のとおりです。

• 文書作成全体/承認の起動

• 購買依頼明細情報を検証

• 文書の自動作成に必要な情報が購買依頼明細にありますか?

• 発注またはリリースを作成して承認

• 購買担当者を取得

「発注文書の作成」項目タイプには、多数の属性も関連付けられています。これらの属性は、Oracle Purchasingアプリケーション表内の情報を参照します。各属性は、関数アクティビティおよびプロセス全体の通知アクティビティによって使用され、保守されます。

「発注文書の作成」ワークフロー項目タイプの属性

「文書作成全体/承認の起動」プロセスの概要

「文書作成全体/承認の起動」プロセスのプロパティを表示するには、このプロセスをナビゲータ・ツリーで選択し、「編集」メニューから「プロパティ」を選択します。「文書作成全体/承認の起動」プロセスの結果タイプは「なし」で、プロセスの完了時には、Oracle Workflow Builderの「参照タイプ」ブランチにある「無効」または「有効」などの特定の結果がないことを示します。サブプロセスには、特定の結果タイプが関連付けられています。

このプロセス・アクティビティは実行可能でもあります。これは、ワークフロー・エンジンのCreateProcessおよびStartProcess APIのコールによってトップ・レベル・プロセスとして実行できることを示します。

「文書作成全体/承認の起動」プロセスは、購買依頼明細が承認され、「自動作成は許可されていますか?」項目属性を「Y」（Yes）に設定したままで、購買依頼明細にソース文書が関連付けられており、ソース・ルールを適切に設定している場合（関連項目: 自動ソースの設定）に開始されます。

このプロセスはノード1で始まります。

ノード2では、「自動作成は許可されていますか?」項目属性がチェックされ、承認済購買依頼明細から文書を自動的に作成するために、このワークフローを開始する必要があるかどうかが確認されます。

自動文書作成が許可されていれば、ノード4で「購買依頼明細情報を検証」サブプロセスが起動され、文書の自動作成に使用できる十分な情報が購買依頼明細に含まれているかどうかがチェックされます。たとえば、このワークフローでは、ソース文書が関連付けられている購買依頼明細のみを自動的に作成できます。

ノード5では、「購買依頼明細情報を検証」サブプロセスにより全購買依頼明細が処理されるまで待機します。

購買依頼の購買依頼明細がすべて処理された後、ノード6で購買依頼がOracle iProcurementで作成された緊急購買依頼であるかどうかがチェックされます。緊急購買依頼には、あらかじめ発注番号が付いています。発注文書の作成ワークフローでは、類似する購買依頼明細が単一の発注またはリリースにグループ化されるまで待機するかわりに、緊急購買依頼明細がノード8で独自発注に入れられます。ワークフローのノード8では、ノード7での購買依頼明細のグループ化がバイパスされ、すべての緊急購買依頼の（同じ緊急発注番号を持つ）明細が1つの発注に入れられます。

他のすべての購買依頼の場合、各購買依頼の購買依頼明細がノード7で適切にグループ化されます。たとえば、1つの購買依頼の2つの購買依頼明細の仕入先、サイト、通貨および購買担当が同一であれば、単一の発注ヘッダー上に作成されます。ノード7では、単一購買依頼の明細が一度に処理されてグループ化されます。

ノード9では、「発注またはリリースを作成して承認」プロセスが起動されます。ノード10では、発注またはリリースが作成されて承認されるまで待機してから、次のアクティビティに移動します。ノード11では、グループ化できるかどうかを調べるために格納されていた一時格納場所から購買依頼明細が削除されます。

「文書作成全体/承認の起動」プロセスのアクティビティ

次に、アクティビティの表示名ごとに各アクティビティの説明を示します。関数アクティビティ・コールであるPL/SQLストアド・プロシージャを除いて、グラフィックなWorkflow Builderのアクティビティに対してすべての構成部品が作成されます。すべての関数アクティビティはPL/SQLストアド・プロシージャを実行するため、ユーザーはPL/SQLストアド・プロシージャをOracle RDBMSに作成および格納する必要があります。PL/SQLストアド・プロシージャの命名規則は、次のとおりです。

<PACKAGE>.<PROCEDURE> 

<PACKAGE>は全プロシージャをグループ化するパッケージの名称で、<PROCEDURE>はプロシージャ名を表します。

「発注文書の作成」プロセスで使用されるパッケージとプロシージャの名称を表示するには、各関数アクティビティの「プロパティ」ページを表示します。たとえば、関数アクティビティ「自動作成は許可されていますか?」では、<PACKAGE>.<PROCEDURE>名にPO_AUTOCREATE_DOC.SHOULD_REQ_BE_AUTOCREATEDが使用されます。

「項目タイプの定義」Webページを使用すると、<PACKAGE>.<PROCEDURE>名を確認できます。関連項目: 『Oracle Workflow開発者ガイド』の「項目タイプの定義」Webページに関する項。

開始（ノード1）

これは標準の関数アクティビティで、単にサブプロセスの開始をマークします。

自動作成は許可されていますか?（ノード2）

この関数アクティビティでは、「自動作成は許可されていますか?」項目属性がチェックされます。この項目属性のデフォルト値は「Y」（Yes）です。値が「Y」の場合、自動文書作成が許可され、ワークフローが続行されます。この属性のデフォルト値をOracle Workflow Builderで「N」（No）に設定すると、自動文書作成を禁止できます。

購買依頼明細情報の検証プロセスを起動（ノード4）

この関数アクティビティでは、処理可能な購買依頼の購買依頼明細がすべて取得され、各購買依頼明細に対して「購買依頼明細情報を検証」プロセスが起動されます。

フロー待ち（ノード5および10）

最初の「フロー待ち」アクティビティは、全購買依頼明細が「購買依頼明細情報を検証」により処理されるまで待機します。第2の「フロー待ち」アクティビティは、発注またはリリースが作成されて承認されるまで待機してから、次のアクティビティに移動します。

これは緊急購買依頼ですか?（ノード6）

緊急購買依頼はOracle iProcurementで作成され、承認と文書作成のためにOracle Purchasingに発行されます。緊急購買依頼には、あらかじめ発注番号が付いています。このワークフローでは、類似する購買依頼明細が単一の発注またはリリースにグループ化されるまで待機するかわりに、購買依頼明細のグループ化がバイパスされ、緊急購買依頼明細が独自発注に入れられます。

注意: Oracle iProcurementでは、単一の緊急購買依頼に複数の仕入先を入れることはできません。

Oracle iProcurementの詳細は、『Oracle iProcurementインプリメンテーションおよび管理ガイド』を参照してください。

購買依頼明細を発注またはリリースにグループ化（ノード7）

「購買依頼明細情報を検証」による全購買依頼明細の処理が完了すると、この関数アクティビティにより、類似する特性を持つ購買依頼明細がグループ化されて同じ文書に作成できるようになります。たとえば、2つの購買依頼明細の仕入先、サイト、通貨および購買担当が同一の場合は、単一の発注ヘッダー上に作成されます。この関数アクティビティでは、Oracle iProcurementで作成されて同じ調達カード番号、仕入先および仕入先サイトを持つ調達カード明細も、単一の発注またはリリースにグループ化されます。

全購買依頼明細を1つの発注に記入（ノード8）

この関数アクティビティでは、同じ緊急発注番号を持つ全緊急購買依頼明細が、単一の発注に入れられます。

発注またはリリースの作成/承認プロセスを起動（ノード9）

この関数アクティビティでは、各文書に対して「発注またはリリースを作成して承認」プロセスが開始されます。次に、事前定義済の承認基準と一致する発注または包括購買リリースが自動的に承認されるように、発注承認ワークフローが開始されます。

一時表から処理済の購買依頼明細を削除（ノード11）

「購買依頼明細情報を検証」プロセスでは、「購買依頼明細を作成候補として一時表に挿入」関数アクティビティにより、自動文書作成試行に使用できる十分な情報を含んだ購買依頼明細が一時表に入れられます。これらの明細は、後で特定の購買依頼明細が特定の発注またはリリースにグループ化される際に、この表から取り出されます。これらの発注またはリリースが作成された後、この一時表にある明細をパージできます。パージは、「一時表から処理済の購買依頼明細を削除」関数アクティビティにより行います。

終了（ノード3および12）

この関数アクティビティはプロセスの終了をマークします。

「購買依頼明細情報を検証」プロセスの概要

「購買依頼明細情報を検証」プロセスのプロパティを表示するには、このプロセスをナビゲータ・ツリーで選択し、「編集」メニューから「プロパティ」を選択します。「購買依頼明細情報を検証」プロセスの結果タイプは「発注購買依頼明細は自動作成可能ですか?」で、プロセスの完了時に結果が「自動作成不可」、「ワークフローから自動作成はできません」、「自動作成に必要な情報が不足」または「購買依頼明細を自動作成可能」となることを示します。これらの結果は、「発注文書の作成」項目タイプの「発注購買依頼明細は自動作成可能ですか?」参照タイプの参照コードに対応します。

このプロセス・アクティビティは実行可能でもあります。これは、ワークフロー・エンジンのCreateProcessおよびStartProcess APIのコールによってトップ・レベル・プロセスとして実行できることを示します。

「購買依頼明細情報を検証」プロセスは、「購買依頼明細情報の検証プロセスを起動」アクティビティにより開始されます。

このプロセスはノード1で始まります。

ノード2では、購買依頼明細から情報が取得されます。ノード3では、「PO: 自動作成の前に見積依頼必須の警告を表示する」プロファイル・オプションの設定がチェックされます。「Yes」に設定され、購買依頼明細が見積依頼になく、購買依頼明細の「見積依頼要」が選択されている場合、ワークフローは警告を発行できないため自動文書作成を中止します。この購買依頼明細は、「文書の自動作成」ウィンドウで使用可能です。それ以外の場合は、購買依頼明細に見積依頼が必須であっても、「PO: 自動作成の前に見積依頼必須の警告を表示する」プロファイル・オプションが「No」に設定されているかぎり、ワークフローによる文書の作成が続行されます。

ノード5では、発注またはリリースの作成に使用できる十分な情報が購買依頼明細にあるかどうかがチェックされます。

ノード7では購買依頼がOracle iProcurementで作成された緊急購買依頼かどうかがチェックされ、ノード8では購買依頼に調達（クレジット）カード番号が関連付けられているかどうかがチェックされます。緊急購買依頼と調達カード購買依頼を作成できるのは、Oracle iProcurementのみです。

購買依頼明細が緊急購買依頼または調達カード購買依頼から取り込まれる場合、ノード12に関連するアクティビティはいずれも実行されません。緊急購買依頼または調達カード購買依頼にはソース文書を関連付ける必要がないため、ワークフローはノード12をスキップし、ノード9に直接移動して続行されます。

注意: 調達カード購買依頼明細にソース文書は不要ですが、包括購買契約などのソース文書に関連付けられている場合、ワークフローでは（後のサブプロセスの「購買依頼明細をグループ化」アクティビティを介して）リリースが作成されます。

他のすべての購買依頼明細の場合、ワークフローではノード12を使用してソース文書タイプが取得されます。ソース文書が見積の場合、またはソース文書が包括購買契約であっても購買依頼明細の対象が単発品目の場合は、ノード9で購買依頼明細が自動文書作成の候補として一時表に挿入され、ワークフローが続行されます。

ソース文書として包括購買契約を持つ購買依頼明細（ノード12で判別）と、単発品目が対象外の購買依頼明細（ノード13で判別）の場合、ワークフローはノード14でリリース生成方法に応じて異なる結果となります。

• リリース生成方法が未指定の場合、ワークフローはノード15で終了します。

• リリース生成方法が「自動リリース/レビュー」または「自動リリース」の場合、ワークフローはそれぞれノード16または17で終了します。かわりに、「リリースの作成」プロセスを介して文書が自動的に作成されます。

• リリース生成方法が「自動作成リリース」の場合は、ノード19で「ワークフローでリリースを作成しますか?」項目属性がチェックされ、Oracle Purchasingでの設定が確認されます。この項目属性を「Y」（Yes）のままにしている場合、ワークフローによりリリースが作成されます。それ以外の場合、ワークフローはノード18で終了し、「文書の自動作成」ウィンドウを介してリリースを作成できます。

注意: 単発品目は承認済仕入先リストでサポートされておらず、承認済仕入先リストではリリース生成方法が指定されているため、ノード14では単発品目のリリース生成方法は取得されません。購買依頼明細の対象が単発品目であっても、包括購買契約にも関連付けられている場合は、ワークフローにより後で「購買依頼明細をグループ化」アクティビティを使用して購買依頼明細からリリースが作成されます。この場合、ワークフローでは、承認済仕入先リストからリリース生成方法を取得する必要はありません。

「購買依頼明細情報を検証」プロセスのアクティビティ

ここでは、「購買依頼明細情報の検証」プロセスの各アクティビティについて、アクティビティの表示名順に説明します。

開始（ノード1）

これは標準の関数アクティビティで、単にサブプロセスの開始をマークします。

購買依頼明細情報を取得（ノード2）

この関数アクティビティでは、購買依頼明細から情報が取得され、その情報で発注文書の作成ワークフロー内の項目属性が更新されます。たとえば、「通貨コード」属性（Oracle Workflow Builderの「属性」下）は、購買依頼明細の「通貨」フィールドの情報で更新されます。

この購買依頼明細に見積依頼は必要ですか?（ノード3）

この関数アクティビティでは、「購買依頼」ウィンドウで「見積依頼要」が選択されているかどうか、「PO: 自動作成の前に見積依頼必須の警告を表示する」プロファイル・オプションが「Yes」に設定されているかどうか、および購買依頼明細が見積依頼に自動作成されていないかどうかがチェックされます。このすべてに該当する場合、ワークフローは「見積依頼要」警告を発行できないため終了します。それ以外の場合はワークフローが続行されます。

文書の作成に必要な情報が購買依頼明細にありますか?（ノード5）

関連項目: 文書の自動作成に必要な情報が購買依頼明細にありますか?

これは緊急購買依頼ですか?（ノード7）

緊急購買依頼はOracle iProcurementで作成され、承認と文書作成のためにOracle Purchasingに発行されます。緊急購買依頼には、あらかじめ発注番号が付いています。このワークフローでは、緊急購買依頼明細にソース文書を必要としないため、緊急購買依頼明細に対する関数アクティビティ「ソース文書タイプを取得」（ノード12）はバイパスされます。

この購買依頼明細は、 調達カード明細ですか?（ノード8）

この関数アクティビティでは、購買依頼明細に調達カード番号が関連付けられているかどうかがチェックされます。調達カード（Pカード）は、Oracle iProcurement購買依頼にのみ使用される法人用クレジット・カードです。

ソース文書タイプを取得（ノード12）

この関数アクティビティでは、購買依頼明細上で参照されるソース文書のタイプ（「包括購買契約」または「見積」）がチェックされます。

REQ 明細に単発品目がありますか?（ノード13）

この関数アクティビティでは、購買依頼明細上で使用される品目のタイプ（「単発」または事前定義済）がチェックされます。

ASLからリリース生成方法を取得（ノード14）

購買依頼明細に事前定義済品目が入力されている場合、この関数アクティビティでは、特定の品目、仕入先および仕入先サイトの組合せに関する承認済仕入先リスト（ASL）エントリが存在するかどうかがチェックされます。次に、ASLで指定されているリリース生成方法が取得されます。

リリース生成方法が「自動リリース」または「自動リリース/レビュー」の場合、Oracle Purchasingの「リリースの作成」プロセスにより購買依頼明細用の包括購買リリースが作成されます。リリース生成方法が「自動作成リリース」の場合は、ワークフローが続行されます。

ワークフローでリリースを作成しますか?（ノード19）

この関数アクティビティでは、「ワークフローでリリースを作成しますか?」属性の値がチェックされます。この属性の値が「Y」（Yes）に設定されている場合は、ワークフローによりリリースが作成されます。それ以外の場合は、「文書の自動作成」ウィンドウを使用してリリースを作成する必要があります。

購買依頼明細を作成候補として一時表に挿入（ノード9）

この関数アクティビティでは、自動文書作成試行に使用できる十分な情報を含んだ購買依頼明細が、一時表に入れられます。これらの明細は、後で特定の購買依頼明細が特定の発注またはリリースにグループ化される際に、この表から取り出されます。これらの発注またはリリースが作成された後、この一時表から明細がパージされます。（パージを実行する関数アクティビティは、「文書作成全体/承認の起動」プロセスの「一時表から処理済の購買依頼明細を削除」です。）

継続フロー（ノード10）

この関数アクティビティでは、「文書作成全体/承認の起動」プロセスの最初の「フロー待ち」関数アクティビティに対して、特定の購買依頼明細に対する「購買依頼明細情報を検証」が正常に完了したことを指示します。このノードでの「フロー待ち」が待機する必要があるのは、他の購買依頼明細の処理のみです。

終了（ノード4、6、11、15、16、17および18）

この関数アクティビティは、プロセスの終了をマークします。アクティビティ自体には結果タイプはありませんが、プロセス内でこのアクティビティの各ノードには処理結果を割り当てる必要があります。処理結果は、アクティビティ・ノードのプロパティ・ページで割り当てます。「購買依頼明細情報の検証」プロセス・アクティビティの結果タイプは「発注REQ明細は自動作成可能ですか」であるため、各終了アクティビティ・ノードの処理結果は、「発注REQ明細は自動作成可能ですか」参照タイプに属する参照コードのいずれか1つと一致する必要があります。

「文書の自動作成に必要な情報が購買依頼明細にありますか?」プロセスの概要

「文書の自動作成に必要な情報が購買依頼明細にありますか?」プロセスのプロパティを表示するには、このプロセスをナビゲータ・ツリーで選択し、「編集」メニューから「プロパティ」を選択します。このプロセスの結果タイプは「Yes/No」で、プロセスの完了時に結果が「Yes」または「No」となることを示します。これらの結果は、「標準」項目タイプの「Yes/No」参照タイプの参照コードに対応します。

このプロセス・アクティビティは実行可能でもあります。これは、ワークフロー・エンジンのCreateProcessおよびStartProcess APIのコールによってトップ・レベル・プロセスとして実行できることを示します。

「文書の自動作成に必要な情報が購買依頼明細にありますか?」プロセスは、「購買依頼明細情報を検証」プロセス内で使用されます。

このプロセスはノード1で始まります。

ノード2では購買依頼明細に十分で適切な仕入先情報があるかどうかがチェックされ、ノード5では購買依頼明細に十分で適切なソース文書情報があるかどうかがチェックされます。この情報は、発注または包括購買リリースの自動作成に必要です。

ノード4で購買依頼が緊急購買依頼であることがわかるか、ノード6で購買依頼が調達カード購買依頼であることがわかった場合、これらの購買依頼にソース文書は必須でないため、ワークフローのノード5でソース文書情報をチェックする必要はありません。緊急購買依頼と調達カード購買依頼を作成できるのは、Oracle iProcurementのみです。

ワークフローのノード8では、文書の自動作成に使用する購買担当が判別されます。

「文書の自動作成に必要な情報が購買依頼明細にありますか?」プロセスのアクティビティ

ここでは、「文書の自動作成に必要な情報が購買依頼明細にありますか?」プロセスの各アクティビティについて、アクティビティの表示名順に説明します。

開始（ノード1）

これは標準の関数アクティビティで、単にサブプロセスの開始をマークします。

購買依頼明細に有効な仕入先情報がありますか?（ノード2）

この関数アクティビティでは、購買依頼明細に有効な仕入先および仕入先サイトがあるかどうかがチェックされます。

これは緊急購買依頼ですか?（ノード4）

緊急購買依頼はOracle iProcurementで作成され、承認と文書作成のためにOracle Purchasingに発行されます。緊急購買依頼には、あらかじめ発注番号が付いています。このワークフローでは、緊急購買依頼明細にソース文書を必要としないため、緊急購買依頼明細に対する関数アクティビティ「REQ 明細に有効なソース文書情報はありますか。」（ノード5）はバイパスされます。

この購買依頼明細は、 調達カード明細ですか?（ノード6）

この関数アクティビティでは、購買依頼明細に調達カード番号が関連付けられているかどうかがチェックされます。調達カード（Pカード）は、Oracle iProcurement購買依頼にのみ使用される法人用クレジット・カードです。

REQ 明細に有効なソース文書情報はありますか。（ノード5）

この関数アクティビティでは、購買依頼明細に有効な（包括購買契約または見積からの）ソース文書情報があるかどうかがチェックされます。特に、ソース文書タイプ、ソース文書およびソース文書明細がチェックされます。

購買担当者を取得（ノード8）

関連項目: 購買担当者を取得

終了（ノード3、7、9および10）

この関数アクティビティは、プロセスの終了をマークします。アクティビティ自体には結果タイプはありませんが、プロセス内でこのアクティビティの各ノードには処理結果を割り当てる必要があります。処理結果は、アクティビティ・ノードのプロパティ・ページで割り当てます。「この購買依頼明細には文書自動作成に必要な情報が揃っていますか?」サブプロセス・アクティビティの結果タイプは「Yes/No」であるため、各終了アクティビティ・ノードの処理結果は、「Yes/No」参照タイプに属する参照コードのいずれか1つと一致する必要があります。

「発注またはリリースを作成して承認」プロセスの概要

「発注またはリリースを作成して承認」プロセスのプロパティを表示するには、このプロセスをナビゲータ・ツリーで選択し、「編集」メニューから「プロパティ」を選択します。「発注またはリリースを作成して承認」プロセスの結果タイプは「発注文書処理済」で、プロセスの完了時に結果が「文書の処理完了」となることを示します。この結果は、「発注文書の作成」項目タイプの「発注文書処理済」参照タイプの参照コードに対応します。

このプロセス・アクティビティは実行可能でもあります。これは、ワークフロー・エンジンのCreateProcessおよびStartProcess APIのコールによってトップ・レベル・プロセスとして実行できることを示します。

「発注またはリリースを作成して承認」プロセスは、「発注またはリリースの作成/承認プロセスを起動」アクティビティにより起動されます。

このプロセスはノード1で始まります。

ノード2では、発注またはリリースが作成されます。正常に作成された文書については、文書が作成されたことを示す通知がノード3で購買担当に送信されます。

ノード4では、「自動承認は許可されていますか?」項目属性が「Y」（Yes）に設定されているかどうかがチェックされます。「Y」に設定されている場合は、ノード5で発注承認ワークフローが起動されて発注またはリリースが承認されます。ノード6では、ワークフローが「文書作成全体/承認の起動」プロセスの最終アクティビティに進む必要があることが示されます。

「発注またはリリースを作成して承認」プロセスのアクティビティ

ここでは、「発注またはリリースを作成して承認」プロセスの各アクティビティについて、アクティビティの表示名順に説明します。

開始（ノード1）

これは標準の関数アクティビティで、単にサブプロセスの開始をマークします。

発注またはリリースを作成（ノード2）

この関数アクティビティでは、購買依頼明細の情報に応じて標準発注または包括購買リリースが作成されます。

発注またはリリースが作成された（ノード3）

文書作成が成功すると、この関数アクティビティによって購買担当に通知が送られます。

自動承認は許可されていますか?（ノード4）

この関数アクティビティでは、「自動承認は許可されていますか?」属性の値がチェックされます。この項目属性が「Y」（Yes）に設定されている場合は、このワークフローにより発注承認ワークフローが起動されて発注またはリリースが承認されます。（この項目属性のデフォルト値はNoを表す「N」です。）

文書承認プロセスを起動（ノード5）

この関数アクティビティにより発注承認ワークフローが起動されます。関連項目: 発注承認ワークフロー。

継続フロー（ノード6）

この関数アクティビティでは、「文書作成全体/承認の起動」プロセスの第2の「フロー待ち」関数アクティビティに対して、「発注またはリリースを作成して承認」プロセスが完了したことが指示されます。「フロー待ち」で待機する必要があるのは、他の文書の処理のみです。

終了（ノード7）

この関数アクティビティは、プロセスの終了をマークします。アクティビティ自体には結果タイプはありませんが、プロセス内でこのアクティビティの各ノードには処理結果を割り当てる必要があります。処理結果は、アクティビティ・ノードのプロパティ・ページで割り当てます。「発注またはリリースの作成と承認」プロセス・アクティビティの結果タイプは「発注文書の処理完了」であるため、各終了アクティビティ・ノードの処理結果は、「発注文書の処理完了」参照タイプに属する参照コードのいずれか1つと一致する必要があります。

「購買担当者を取得」サブプロセスの概要

「購買担当者を取得」プロセスのプロパティを表示するには、このプロセスをナビゲータ・ツリーで選択し、「編集」メニューから「プロパティ」を選択します。「購買担当者を取得」プロセスの結果タイプは「発注処理結果」で、プロセスの完了時に結果が「処理失敗」または「処理完了」となることを示します。これらの結果は、「発注文書の作成」項目タイプの「発注処理結果」参照タイプの参照コードに対応します。

このプロセス・アクティビティは実行不可で、最上位レベル・プロセスとしては開始できませんが、上位レベル・プロセスによりコールされた場合にサブプロセスとしてのみ実行できます。

このプロセスでは、発注の購買担当情報が取得されます。ノード2では、購買依頼明細の「購買担当」フィールドから有効な購買担当名が取得されます。このフィールドで購買担当が指定されていない場合は、ノード4で「マスター品目」ウィンドウの品目定義からデフォルト購買担当が取得されます。このウィンドウで購買担当が指定されていない場合、ノード6では「購買担当の定義」ウィンドウで購買担当に割り当てられているデフォルト・カテゴリが取得されます。このウィンドウでも購買担当が指定されていない場合は、ノード8で購買依頼明細に関連付けられているソース文書から購買担当が取得されます。リリースの作成時に、このサブプロセスにより包括購買契約から購買担当名が取得されます。

ワークフローで購買担当が検出されなければ、文書は作成されません。ただし、購買依頼明細はOracle Purchasingの「文書の自動作成」ウィンドウで引き続き使用できます。

「購買担当者を取得」サブプロセスのアクティビティ

ここでは、「購買担当の取得」プロセスの各アクティビティについて、アクティビティの表示名順に説明します。

開始（ノード1）

これは標準の関数アクティビティで、単にサブプロセスの開始をマークします。

購買依頼明細から購買担当者を取得（ノード2）

この関数アクティビティでは、最初に購買依頼明細からの購買担当の取得が試行されます。

項目から購買担当者を取得（ノード4）

「購買依頼明細から購買担当者を取得」に失敗すると、この関数アクティビティにより、「マスター品目」ウィンドウで品目に割り当てられている購買担当の取得が試行されます。

カテゴリから購買担当者を取得（ノード6）

「項目から購買担当者を取得」に失敗すると、この関数アクティビティにより、購買依頼明細上でカテゴリに割り当てられている購買担当の取得が試行されます。

ソース文書から購買担当者を取得（ノード8）

「カテゴリから購買担当者を取得」に失敗すると、この関数アクティビティにより、購買依頼明細に関連付けられているソース文書からの購買担当の取得が試行されます。複数の購買担当が割り当てられている場合、または購買担当が割り当てられていない場合、この関数アクティビティは失敗します。

終了（ノード3、5、7および9）

この関数アクティビティは、プロセスの終了をマークします。アクティビティ自体には結果タイプはありませんが、プロセス内でこのアクティビティの各ノードには処理結果を割り当てる必要があります。処理結果は、アクティビティ・ノードのプロパティ・ページで割り当てます。「購買担当の取得」サブプロセス・アクティビティの結果タイプは「発注処理結果」であるため、各終了アクティビティ・ノードの処理結果は、「発注処理結果」参照タイプに属する参照コードのいずれか1つと一致する必要があります。

発注文書作成ワークフローでのワークフロー・モニターの使用方法

ワークフローの進行中に文書をモニターするには、モニター対象となる文書とそのモニター先プロセスの両方に固有の項目キーをワークフロー・モニターに入力する必要があります。

ワークフロー・モニターの使用方法は、『Oracle Workflowユーザーズ・ガイド』のワークフロー監視の概要に関する項を参照してください。

発注文書の作成ワークフローの項目キーを判別する手順は、次のとおりです。

1. モニターしている購買依頼の購買依頼番号を書き留めます。

2. 次のSQL*文を記述してREQUISITION_HEADER_IDを検索します。（REQUISITION_HEADER_IDは、「購買依頼」ウィンドウに表示されない内部番号です。）

   たとえば、購買依頼番号が12012570の場合は、次のSQL*文を記述します。

   select requisition_header_id

   from   po_requisition_headers_all

   where  segment1='12012570';

   REQUISITION_HEADER_IDが戻されます。

3. ステップ2で戻されたREQUISITION_HEADER_IDを使用して次のSQL*文を記述し、「文書作成全体/承認の起動」プロセスの項目キーを検索します。

   たとえば、REQUISITION_HEADER_IDが1024961の場合は、次のSQL*文を記述します。

   select item_type, item_key, root_activity  

   from   wf_items

   where  item_key like '1024961'||'%'

   and    item_type='CREATEPO'

   and    root_activity='OVERALL_AUTOCREATE_PROCESS';

   「文書作成全体/承認の起動」プロセス中に表示される購買依頼の項目キーが戻されます。次に例を示します。

      ITEM_TYP  ITEM_KEY            ROOT_ACTIVITY 

      --------  ------------------  ------------------------

      CREATEPO  1024961-12374       OVERALL_AUTOCREATE_PROCESS

   次に、他の「発注文書の作成」プロセス中に表示される購買依頼の一意項目キーを識別する必要があります。これにより、その購買依頼をワークフロー全体で常にモニターできます。これについては次のステップで説明します。

4. ステップ3で戻されたITEM_KEYと次のSQL*文を使用して、他の2つのワークフロー・プロセス「購買依頼明細情報を検証」および「文書の作成と承認」のITEM_KEYを検索します。

   たとえば、ITEM_KEYが1024961-12374の場合は、次のSQL*文を記述します。

   select item_type, item_key, root_activity

   from   wf_items

   where  parent_item_type = 'CREATEPO'

   and    parent_item_key  = '1024961-12374';

   REQ_LINE_PROCESSINGにより、購買依頼明細ごとに項目キーが戻されます。CREATE_AND_APPROVE_DOCにより、発注ごとに項目キーが戻されます。次に例を示します。

      ITEM_TYP  ITEM_KEY   	    ROOT_ACTIVITY 

      --------- -------------------  ------------------------

      CREATEPO  1025575-12375         REQ_LINE_PROCESSING

      CREATEPO  1004590-12376         CREATE_AND_APPROVE_DOC

   プロセス「購買担当者を取得」および「文書の自動作成に必要な情報が購買依頼明細にありますか?」は、他のプロセスのサブプロセスであるため、これらのサブプロセスの項目キーを検索する必要はありません。項目キーを使用しなくても、これらのサブプロセスにはワークフロー・モニターを介してドリルダウンできます。

受入確認ワークフロー

受入確認ワークフローでは、Oracle PurchasingまたはOracle iProcurementを介して購買依頼を作成した依頼者または購買担当に、Web、Eメールまたは「通知要約」ウィンドウを介して通知が送信されます。これにより、ユーザーには品目が受入済であることがわかります。

「受入確認」ワークフローでは、「搬送先」または搬送先タイプが「費用」で、「経路」が「直送」で、今日の日付以降の「希望入手日」が指定されている品目について、通知が送られます。

このワークフローでは、ワークフロー・バックグラウンド・プロセスおよび「受入確認ワークフロー発注の選択」プロセスが実行中である必要があります。関連項目: 受入確認ワークフロー発注の選択。

受入確認ワークフローのカスタマイズ

ワークフローをカスタマイズするには、Oracle Workflow Builderを使用します。ワークフローをカスタマイズした場合、そのワークフローの影響を受けるのは、カスタマイズ後に作成する文書のみです。

ワークフロー・モニターを使用すると、ワークフロー・プロセス内の特定の文書の位置をたどることができます。関連項目: 『Oracle Workflowユーザーズ・ガイド』のワークフロー監視の概要に関する項。

Oracle Workflow Builderでワークフローを表示する手順は、次のとおりです。

1. 「ファイル」メニューから「オープン」を選択して、データベースに接続します。

   関連項目: 『Oracle Workflow開発者ガイド』の項目タイプのオープンと保存に関する項

   このワークフローの表示名は「発注受入確認」です。ワークフロー定義ファイル名はpoxwfrcv.wftです。

   

2. データ・ソースを拡張し、そのデータ・ソース内で「発注受入確認」項目タイプのブランチを拡張します。

3. 「発注受入確認」ブランチ内の「プロセス」ブランチを拡張し、プロセス・アクティビティをダブルクリックしてダイアグラムを表示します。

新規カスタム処理の作成

発注受入確認ワークフローをカスタマイズする場合は、Oracle Purchasingに用意されているデフォルト（オリジナル）ワークフローをカスタマイズする必要があります。Oracle Purchasingの発注承認、購買依頼の承認および発注文書の作成ワークフローとは異なり、アプリケーション自体からコールできる発注受入確認ワークフローは1つのみです。「文書タイプ」ウィンドウ内の他のワークフローのように個別カスタマイズを選択することはできません。したがって、デフォルト・ワークフローをカスタマイズする必要があります。カスタマイズのテスト中に必要に応じて元に戻せるように、必ずバックアップを用意してください。

必要な変更

発注受入確認ワークフロー自体に必須の変更はありません。ただし、受入確認ワークフローを動作させるには、ワークフロー・バックグラウンド・プロセスおよび「受入確認ワークフロー発注の選択」プロセスを発行する必要があります。関連項目: 受入確認ワークフロー発注の選択。

オプションのカスタマイズ

依頼者に受入確認への応答を催促するまでの期間を変更できます。そのためには、「要求者に通知」サブプロセスでの通知ごとに「管理プロパティ」ウィンドウに独自のタイムアウト間隔を入力します。

これらの通知には、依頼者に受入確認への応答を催促するまでのデフォルト・タイムアウト期間が用意されていますが、このタイムアウトはビジネス・ニーズにあわせて変更できます。

デフォルトのタイムアウト間隔を変更する手順は、次のとおりです。

1. 「要求者に通知」プロセスの次のいずれかの通知アクティビティを選択します。

2. 要求者に受入を確認するように通知 - 最初の通知

3. 要求者に受入を確認するように通知 - 1回目の催促

4. 要求者に受入を確認するように通知 - 2回目の催促

5. 通知の「プロパティ」ウィンドウをオープンし、次の催促が送信されるまでのタイムアウト期間、または最後の催促がタイムアウトして依頼者のマネージャに通知が送信されるまでのタイムアウト期間を変更します。手順は、『Oracle Workflowガイド』および『Oracle Workflow開発者ガイド』を参照してください。

サポートされるカスタマイズとサポートされないカスタマイズ

この項では、発注受入確認ワークフローについて、変更可能な内容と変更不可の内容を説明します。変更可能な内容については、カスタマイズする際に注意を必要とする重要なガイドラインについても説明します。

ワークフローのカスタマイズ方法に関する重要情報は、『Oracle Workflow開発者ガイド』を参照してください。

重要: 以降の各項で、特定のワークフロー・オブジェクトがカスタマイズ可能オブジェクトのリストに記載されていない場合は、アクセス・レベルに関係なく変更しないでください。

属性

発注受入確認ワークフローの項目属性はいずれも変更できません。ただし、項目属性を追加することはできます。

プロセス

プロセスを変更する場合は、データベース内のデータの整合性を維持するために基本的なフローをそのまま保つことが重要です。

• デフォルト・プロセスのデフォルト関数アクティビティによって設定される属性は、デフォルト関数アクティビティを独自のものに置き換えた場合も設定される必要があります。つまり、そのプロセス内の関数アクティビティがSetItemAttr文を使用している場合、その関数アクティビティは後で他の関数アクティビティに使用される属性を設定します。したがって、新しい関数アクティビティも同じ属性を設定する必要があります。また、 SetItemUserKey文およびSetItemOwner文があれば、それも保存する必要があります。（カスタマイズの内容によっては、GetItemAttr文も保存してください。）

• デフォルト・プロセスが保守しているデータベースの状態は、カスタマイズしたプロセスでも保守する必要があります。つまり、カスタマイズしたプロセスの関数アクティビティでUpdate文またはInsert Into文を使用する場合、その関数アクティビティは、データベースの行を更新または挿入します。したがって、新規の関数アクティビティは、データベースを同じ状態に保守する必要があります。

  SetItemAttr文、GetItemAttr文、SetItemUserKey文、SetItemOwner文、Insert Into文またはUpdate文を使用するワークフロー関数アクティビティのリストを取得するには、PL/SQLスクリプトpowfcustを実行します。このスクリプトの実行手順は、「カスタマイズのガイドライン」を参照してください。

次の各プロセスからはデフォルトの関数アクティビティを削除しないでください。ただし、独自の関数アクティビティを追加することはできます。

• 受入の確認プロセス

• 要求者に通知

通知

「要求者に通知」プロセスの「受入の確認」の「要求者に通知」通知のタイムアウト機能を除き、「発注受入確認」の通知は変更できません。

関数アクティビティ

発注受入確認ワークフローの関数アクティビティは変更できません。

ただし、一部の関数アクティビティは、独自の関数アクティビティに置き換えることができます。関数アクティビティを置き換える場合は、それを含んでいるプロセスを変更します。関連項目: 前述の「プロセス」の「発注受入確認」プロセスのカスタマイズのガイドライン。

プロセスのデフォルト関数アクティビティを独自作成した関数アクティビティに置き換える場合は、次の点に注意する必要があります。

• 新しい関数アクティビティの結果タイプは、デフォルト・アクティビティの結果タイプと一致する必要があります。つまり、Oracle Workflow Builderにおける関数アクティビティの「結果タイプ」は、その関数アクティビティの対応するPL/SQLプロシージャで指定する結果タイプと一致する必要があります（「Yes/No」結果タイプなど）。また、関数アクティビティおよび対応するPL/SQLプロシージャに2つの結果（「Yes」と「No」など）がある場合は、ワークフロー・ダイアグラム内に2つの対応する遷移が（「Yes」に1つと「No」に1つ）存在することも確認してください。プロセスの結果タイプと遷移を変更する場合は、特別な遷移やチェックを削除またはバイパスしないように注意する必要があります。

• 前述の「プロセス」と同様に、デフォルト関数アクティビティにより設定されていた属性は、カスタマイズした関数アクティビティでも設定する必要があります。

• 前述の「プロセス」と同様に、デフォルト関数アクティビティにより維持されていたデータベース・ステータス性は、カスタマイズした関数アクティビティでも設定する必要があります。

メッセージ

「発注受入確認」のメッセージは、いずれもビジネス・ニーズにあわせて変更できます。

関連項目: 『Oracle Workflow開発者ガイド』のメッセージ結果に関する項、および『Oracle Workflow開発者ガイド』のメッセージの作成に関する項

参照タイプ

「発注受入確認」の参照タイプはいずれも変更できません。

受入確認ワークフローの項目タイプ

受入確認ワークフローのプロセスは、「発注受入確認」という項目タイプに関連付けられています。この項目タイプにより、受入確認に使用可能なワークフロー・プロセスがすべて識別されます。「発注受入確認」に関連付けられているワークフロー・プロセスは、次のとおりです。

• 受入の確認プロセス

• 要求者に通知

「PO受入確認」項目タイプには、多数の属性も関連付けられています。これらの属性は、Oracle Purchasingアプリケーション表内の情報を参照します。各属性は、関数アクティビティおよびプロセス全体の通知アクティビティによって使用され、保守されます。

「発注受入確認」ワークフロー項目タイプの属性

「受入の確認」プロセスの概要

「受入の確認」プロセスのプロパティを表示するには、このプロセスをナビゲータ・ツリーで選択し、「編集」メニューから「プロパティ」を選択します。「受入の確認」プロセスの結果タイプは「なし」で、プロセスの完了時には、Oracle Workflow Builderの「参照タイプ」ブランチにある「終了（無効）」または「終了（有効）」などの特定の結果がないことを示します。かわりに、このプロセスのサブプロセスには、特定の結果タイプが関連付けられています。

プロセス・アクティビティの「詳細」プロパティ・ページは、「受入の確認」プロセスにDEFAULT_ERRORというエラー・プロセスが関連付けられていることを示します。このエラー・プロセスは、プロセス内でエラーが発生した場合にのみ開始されます。たとえば、ワークフローにより依頼者のマネージャに通知が送信される場合に、マネージャの一意識別子（マネージャID）が見つからないと、ワークフロー・エンジンは通知アクティビティを実行しようとした時点でエラーを呼び出します。このエラーにより、デフォルト・エラー・プロセスであるDEFAULT_ERRORが開始されます。デフォルト・エラー・プロセスは、「システム: エラー」項目タイプに関連付けられています。現在、このプロセスでは単に標準の「デフォルト・エラー通知」アクティビティが実行され、エラーに関連した情報が提供されます。このプロセスは、ニーズにあわせてさらにカスタマイズできます。関連項目: 『Oracle Workflow開発者ガイド』のデフォルト・エラー・プロセスに関する項。

このプロセス・アクティビティは実行可能でもあります。これは、ワークフロー・エンジンのCreateProcessおよびStartProcess APIのコールによってトップ・レベル・プロセスとして実行できることを示します。

「受入の確認」プロセスは、「要求」ウィンドウを介して「受入確認ワークフロー発注の選択」プロセスを発行すると始まります。

このワークフローはノード1で始まります。

ノード1では、購買担当または依頼者への送信メッセージに使用される発注と購買依頼から情報が取得されます。

ノード2では、Oracle iProcurementがインストールされていれば、Oracle iProcurementを介して受入確認を処理する必要がある場合に、通知からOracle iProcurementの「オーダーの受入」Webページにアクセスできるように、URLが取得されます。

ノード3では、このサブプロセスにより、納期を超過している費用品目の受入を確認するように求める通知が依頼者に送信されます。

依頼者が「未受入」で応答すると、品目が未受入であることがノード4で購買担当に通知されます。依頼者が「一部/超過受入」で応答すると、その旨がノード5で購買担当に通知されます。依頼者が「全部受入」で応答すると、ノード6で受入が処理されます。受入を処理できなければ、ノード7で依頼者に失敗通知が送信され、ノード9で購買担当に失敗通知が送信されます。

ノード3では、ノード3のサブプロセスで通知アクティビティにより示された日数が経過するまでに依頼者が応答しないと、ワークフローがタイムアウトし、階層設定から依頼者のマネージャが取得され（ノード10）、依頼者のマネージャに通知されます（ノード11）。

「受入の確認」プロセスのアクティビティ

次に、アクティビティの表示名ごとに各アクティビティの説明を示します。関数アクティビティ・コールであるPL/SQLストアド・プロシージャを除いて、グラフィックなWorkflow Builderのアクティビティに対してすべての構成部品が作成されます。すべての関数アクティビティはPL/SQLストアド・プロシージャを実行するため、ユーザーはPL/SQLストアド・プロシージャをOracle RDBMSに作成および格納する必要があります。PL/SQLストアド・プロシージャの命名規則は、次のとおりです。

<PACKAGE>.<PROCEDURE> 

<PACKAGE>は全プロシージャをグループ化するパッケージの名称で、<PROCEDURE>はプロシージャ名を表します。

「発注受入確認」プロセスで使用されるパッケージとプロシージャの名称を表示するには、各関数アクティビティの「プロパティ」ページを表示します。たとえば、関数アクティビティ「要求者のマネージャを取り出す」では、<PACKAGE>.<PROCEDURE>名にPORCPTWF.GET_REQUESTER_MANAGERが使用されます。

「項目タイプの定義」Webページを使用すると、<PACKAGE>.<PROCEDURE>名を確認できます。関連項目: 『Oracle Workflow開発者ガイド』の「項目タイプの定義」Webページに関する項。

発注情報を取り出す（ノード1）

この関数アクティビティでは、PO_HEADER_ID、EXPECTED_RECEIPT_DATEおよびREQUESTER_IDが検索基準として使用され、RCV_CONFIRM_RECEIPT_V表から発注および購買依頼情報が取得されます。取得されたデータは、「要求者に通知」サブプロセスで受注ヘッダーおよび受注明細データを含む通知メッセージの送信に使用されます。

「発注の受入」WebページURLを取り出す（ノード2）

この関数アクティビティでは、Oracle iProcurementを介して設定した「オーダーの受入」WebページのURLが取得されます。このURLは、ワークフロー通知メッセージから「オーダーの受入」Webページへの直接リンクを提供します。Oracle iProcurementをインストール済の場合は、Oracle iProcurementを介して、このWebページで受入確認を処理できます。

要求者のマネージャを取り出す（ノード10）

「要求者に通知」サブプロセスの通知アクティビティで示された日数が経過するまでに依頼者が応答しなければ、この関数アクティビティにより階層設定からマネージャのユーザー名が取得されます。ワークフローでは、そのマネージャに通知されます。

受入取引の処理（ノード6）

この関数アクティビティでは、ワークフロー通知に対する応答が「全部受入」の場合に、「受入オープン・インタフェース」で取引が処理されます。これにより、納入が引き続きオープンであることが保証されます。この場合、「受入オープン・インタフェース」プログラムにより起動され、受入レコードが受入取引オープン・インタフェース表に挿入されます。

次に、受入取引マネージャが（「RCV: 処理モード」プロファイル・オプションの設定に関係なく）オンライン・モードでコールされ、受入レコードが即時に処理されます。エラーがある場合は、その旨を示す通知が「受入取引が失敗したことを通知」アクティビティにより送信されます。

要求者のマネージャにタイムアウトを通知（ノード11）

「要求者に通知」サブプロセスの通知アクティビティにより示された日数が経過するまでに依頼者が応答しなければ、この関数アクティビティにより依頼者のマネージャに通知されます。

受入取引が失敗したことを通知（ノード7および9）

「受入の確認」プロセスには、このアクティビティが2つあります。これらのアクティビティは、受入を作成できない場合（受入取引マネージャが起動されなかった場合、またはすでに他のユーザーが「受入」ウィンドウで受入を作成済の場合など）に使用されます。一方のアクティビティでは、受入を作成できなかったことを示す通知が依頼者に送信され、他方のアクティビティでは同じ通知が購買担当に送信されます。Web上では、このアクティビティにより即時にエラー・メッセージが画面に表示されます。また、このアクティビティにより正式通知が標準の通知キューに送られます。

購買担当者に一部受入を通知（ノード5）

依頼者が「要求者に通知」サブプロセス・アクティビティで「一部/超過受入」を使用して応答すると、品目が一部受入済または超過受入済であることが、このアクティビティにより購買担当に通知されます。通知は、予想された受入数量と実際の受入数量を示します。

購買担当者に未受入を通知（ノード4）

依頼者が「要求者に通知」サブプロセスで「未受入」を使用して応答すると、品目が未受入であることが、このアクティビティにより購買担当に通知されます。

終了（ノード12）

このアクティビティでプロセスが終了します。

「要求者に通知」サブプロセスの概要

「要求者に通知」プロセスのプロパティを表示するには、このプロセスをナビゲータ・ツリーで選択し、「編集」メニューから「プロパティ」を選択します。「要求者に通知」プロセスの結果タイプは「要求者に通知応答」で、プロセスの完了時に結果が「全部受入」、「未受入」、「一部/超過受入」または「タイム・アウト」となることを示します。これらの結果は、「発注受入確認」項目タイプの「要求者に通知応答」参照タイプの参照コードに対応します。

このプロセス・アクティビティは実行可能でもあります。これは、ワークフロー・エンジンのCreateProcessおよびStartProcess APIのコールによってトップ・レベル・プロセスとして実行できることを示します。

このプロセスでは、納期を超過している費用品目の受入を確認するように求める通知が依頼者に送信されます。依頼者は、その品目について「未受入」、「一部/超過受入」または「全部受入」で応答できます。

ノード1、5および6の通知アクティビティには、次のデフォルト・タイムアウト日数が含まれています。

• 要求者に受入を確認するように通知 - 最初の通知（ノード1）: 7日

• 要求者に受入を確認するように通知 - 1回目の催促（ノード5）: 7日

• 要求者に受入を確認するように通知 - 2回目の催促（ノード6）: 1日