機械翻訳について

購買依頼属性

この表は、購買依頼の承認ルーティング・ルールを作成するために使用できる3つの購買依頼ディメンション内のすべての属性を示しています。 承認ルールで使用する場合、アスタリスク(*)でマークされた属性は、空白のルールではないことを明示的に指定する必要があります。

これらはヘッダー・レベル属性です。

属性	ノート
変更済明細の承認金額の変更	変更済明細の当初承認金額と変更済明細の新規承認金額(控除対象外税金を含む)の差異の金額。
変更済明細の購買依頼金額の変更	変更済明細の当初購買依頼金額と変更済明細の新規購買依頼金額との差異の金額。
文書会計分類	税金属性
緊急購買依頼	購買依頼が緊急購買依頼かどうかを示します。
機能通貨	購買依頼発行BUの通貨コード
残余予算チェック失敗または警告	購買依頼発行時の資金チェックに警告があることを識別します。
資金上書き承認者	資金上書きのリクエストを承認できるユーザー。
資金上書き承認者ユーザー名	資金上書きのリクエストを承認できるユーザーの名前。
ヘッダー属性カテゴリ	購買依頼ヘッダーの属性カテゴリ
*ヘッダー番号属性1 - 20	数値付加フレックスフィールド属性
ヘッダー・テキスト属性1 20	テキスト付加フレックスフィールド属性
資金不足	購買依頼が資金上書きリクエストとともに送信されたかどうかを示します。
インタフェース・ソース・コード	インポート・ソースを識別するために購買依頼インポートで使用されます。
社内転送購買依頼	社内品目を含む購買依頼です。
元帳	購買依頼発行BUに使用する元帳。
変更済明細の新規承認金額	カタログまたは分割操作からの更新中に追加された新規明細の金額と控除対象外税金を含む合計。
変更済明細の新規購買依頼金額	カタログまたは分割操作からの更新中に追加された新規明細の合計金額。
変更済明細の当初承認金額	控除対象外税金を含む、置換済または分割明細の金額。
変更済明細の当初購買依頼金額	置換または分割明細の金額(税抜)。
*上書き承認者	アプリケーション生成の承認者を上書きするために指定された承認者。
*上書き承認者職階ID	ポジション・チェーンまたは承認チェーンが承認者を上書きしているときにポジション階層ルーティングで使用される属性(BPMからのみサポート)。
変更済明細の承認金額のパーセント変更	変更済明細の当初承認金額と変更済明細の新規承認金額の間の差異(控除対象外税金を含む)。
変更済明細の購買依頼金額の変更率	変更済明細の当初購買依頼金額と変更済明細の新規購買依頼金額との差異のパーセント。
作成者	購買依頼を発行した個人。
作成者部門ID	購買依頼を発行した個人の部門ID。
作成者部門名	購買依頼を発行した個人の部門名。
*作成者等級コード	購買依頼を発行した個人の等級コード。
作成者ジョブ	購買依頼を送信した個人のジョブ・コード。
作成者ジョブ・レベル	購買依頼を発行した個人のジョブ・レベルです。
*作成者のポジション	購買依頼を発行した個人のポジションID。
作成者ユーザー名	購買依頼を発行した個人のユーザー名。
購買依頼金額	購買依頼の合計金額。
購買依頼承認金額	控除対象外税がある購買依頼金額。
購買依頼DFFコンテキスト	購買依頼header(only supported from BPM)の付加フレックスフィールド・コンテキスト。
購買依頼発行BU	購買依頼が作成されるBUです。
課税国	トランザクションが課税目的で行われたとみなされる国です。
購買依頼摘要	値を入力するための自由形式のテキストを表示します。
購買依頼BU名	値を入力するための自由形式のテキストを表示します。

この表は、購買依頼明細レベルの属性を示しています。

属性	ノート
*契約	購買依頼明細の契約番号。
*契約バイヤー	購買依頼明細の契約のバイヤー。
*契約ヘッダー・リリース済金額	購買依頼明細の契約のヘッダーのリリース金額。
*契約明細	購買依頼明細の契約の明細番号。
*契約明細金額	購買依頼明細の契約の契約明細金額。
契約明細超過金額インジケータ	購買依頼明細金額が契約明細限度額を超えている場合はTrue。
*契約明細超過金額	購買依頼明細金額が契約明細限度額を超過している金額です。
*評価額	税務当局が税金計算のために製品を評価する消費価格。
割当済バイヤー	購買依頼明細を処理するために割り当てられたバイヤー。
割当済バイヤー・ユーザー名	割当済バイヤーのユーザー名。
カテゴリ名	購買依頼明細のカテゴリの名前。
搬送先事業所	リクエストの配信先のロケーション。
搬送先組織	リクエストの搬送先となる事業所の組織。
搬送先タイプ	搬送先のタイプ(費用または在庫)。
危険度区分	購買依頼明細の危険度分類です。
*用途	製品の使用目的に基づく税金分類。
品目	品目番号
品目改訂	購買依頼明細の品目の改訂番号。
品目ソース	カタログ外リクエスト、パンチアウト・カタログ、ローカル・カタログなど、品目の追加元となるソースを識別します。
明細金額	購買依頼明細の合計金額。
明細承認金額	控除対象外税金のある明細金額。
明細DFFコンテキスト	購買依頼line(only supported from BPM)の付加フレックスフィールド・コンテキスト。
明細属性カテゴリ	購買依頼明細の属性カテゴリです。
*明細番号属性1 - 20	数値付加フレックスフィールド属性
明細テキスト属性1 - 20	テキスト付加フレックスフィールド属性
明細タイプ	明細タイプ(商品や金額ベースなど)
製造業者	リクエストの製造元。
製造業者部品番号	リクエストの製造業者部品番号。
ネゴシエーション要	購買依頼明細にネゴシエーションが必要かどうかを示します。
新規サプライヤ	購買依頼明細に新規サプライヤが指定されているかどうかを示します。
*価格	機能通貨での購買依頼明細の価格です。
調達カード	調達カードが使用されるかどうかを示します。
調達カテゴリ階層(レベル1) - 10)	組織が購入する製品を分類するために使用されるカテゴリ階層。
製品カテゴリ	トランザクション時に入力された品目のカテゴリに基づく税分類です。
^製品会計分類	税金の製品を分類するために使用され、適用可能な税分類です。
製品タイプ	製品のタイプ(商品など)に基づく税分類。
*数量	リクエスト数量
要求者	明細がリクエストされた個人。
リクエスト者部門ID	明細がリクエストされた個人の部門ID。
リクエスト者部門名	明細がリクエストされた個人の部門名
*依頼者等級コード	明細がリクエストされた個人の等級コード。
リクエスト者ジョブ	明細がリクエストされた個人のジョブ・コード。
依頼者ジョブ・レベル	明細がリクエストされた個人のジョブ・レベルです。
依頼者レベル1 - 10監督者ユーザー名	依頼者の監督階層の上位10人の就業者のユーザー名。 依頼者レベル1監督者ユーザー名は、最上位就業者のユーザー名です。
依頼者レベル1 -10監督者	依頼者の監督階層チェーンの上長。 依頼者レベル1監督者が監督チェーンの最上位ワーカーです。
*依頼者ポジション	明細がリクエストされた個人のポジションID。
リクエスト者のユーザー名	明細がリクエストされた個人のユーザー名。
*スマート・フォーム	購買依頼明細のスマート・フォームの名前。
ソース組織	社内資材転送で品目を搬送先在庫に供給する在庫組織。
ソース・タイプ	購買依頼明細の供給ソースのタイプを示します。たとえば、在庫組織の場合はソース・タイプが内部、サプライヤの場合は外部です。
*保管場所	搬送先タイプが在庫の場合、リクエストの搬送先となる保管場所。
*提示バイヤー	購買依頼明細の提示バイヤーです。
*仕入先	リクエスト明細のサプライヤ。
サプライヤ構成ID	構成可能品目の識別に使用されるID。
サプライヤD-U-N-S	サプライヤの識別子です。
サプライヤ品目	リクエストされた明細のサプライヤ品目番号。
*サプライヤ・サイト	サプライヤがリクエストを処理するサイト。
税分類	税金決定のためにトランザクションに入力された税分類コードです。
トランザクション・ビジネス・カテゴリ	トランザクション・タイプの定義(購買トランザクションなど)のためにトランザクション明細を分類するために使用される税分類です。
国連番号	危険物質識別子
UNSPSC	リクエストの分類に使用される国連標準製品およびサービス・コード
単位	リクエストされた明細の単位。
緊急	明細が緊急リクエストかどうかを示します。
ユーザー定義会計分類	税金決定およびレポートを促進するためのトランザクションの分類に使用されるユーザー定義税分類です。
カテゴリ名	値を入力するための自由形式のテキストを表示します。
サプライヤ組織タイプ	値を入力するための自由形式のテキストを表示します。
作成者によりネゴシエーション済	値を入力するための自由形式のテキストを表示します。
使用可能包括金額	値を入力するための自由形式のテキストを表示します。
搬送先事業所コード	値を入力するための自由形式のテキストを表示します。

この表には購買依頼配分レベル属性が含まれています。

属性	ノート
助成所有ビジネス・ユニット	許可交付を管理および所有するビジネス・ユニット。
交付目的	交付が資金供給するアクティビティの摘要。 たとえば、研究または臨床試験です。
助成タイプ	交付の分類です。 たとえば、連邦政府許可や民間許可などです。
貸借一致セグメント値	勘定体系の貸借一致セグメント。
契約	交付契約の表示名。
手数料勘定	リクエストされた品目を請求する必要がある勘定科目です。
勘定体系	ビジネス・ユニットに関連付けられた勘定体系の名前。
コスト・センター	会計目的で原価が請求される組織内のユニットです。
*コスト・センター・マネージャ	会計目的で原価が請求される組織内のユニットの管理者。
コスト・センター・マネージャ・ユーザー名	会計目的で原価が請求される組織内のユニットの管理者のユーザー名。
配分金額	配分の合計金額。
配分承認金額	控除対象外税を含む配分金額。
配分属性カテゴリ	購買依頼配分の属性カテゴリです。
配分DFFコンテキスト	購買依頼distribution(only supported from BPM)の付加フレックスフィールド・コンテキスト。
*配分番号属性1 - 20	数値付加フレックスフィールド属性
配分テキスト属性1 - 20	テキスト付加フレックスフィールド属性
*支出組織	支出が発生し、プロジェクトの財務プランを保持する組織。
*支出タイプ	プロジェクトの計画、予算、予測、レポートなど、直接費の計算など、各支出品目に割り当てられたコストの分類。
資金調達先	交付に関連付けられた資金のソースの表示名です。
勘定科目	勘定体系の勘定科目セグメント。
主要調査員	報奨のパフォーマンスを担当する個人。
主要調査員ユーザー名	報奨のパフォーマンスを担当する個人のユーザー名。
*プロジェクト	プロジェクト・ビジネス管理の名前
請求可能なプロジェクト	プロジェクトが請求可能かどうかを示します。 リリース13 Update Cで入手できます。
資産計上可能なプロジェクト	プロジェクトが大文字であるかどうかを示します。 リリース13 Update Cで入手できます。
プロジェクト資金ソース	プロジェクトに資金を供給するパーティ(外部顧客または内部組織など)。 リリース13 Update Cで入手できます。
プロジェクト・マネージャ	プロジェクトのプロジェクト・マネージャ。
プロジェクト・マネージャのユーザー名	プロジェクト・マネージャのユーザー名。
プロジェクト所有ビジネス・ユニット	プロジェクトを所有するビジネス・ユニットの表示名。
プロジェクト予約属性1 - 10	プロジェクト・コスト収集フレックスフィールドで将来使用するために予約されています。 リリース13 Update Cで入手できます。
プロジェクト・タイプ	プロジェクト・ビジネスが管理するプライマリ分類。
プロジェクト・ユーザー定義属性1 - 10	プロジェクト原価収集フレックスフィールドのユーザー定義セグメント。 リリース13 Update Cで入手できます。
プロジェクト作業タイプ	プロジェクト・タスクに関連付けられた作業の分類。 リリース13 Update Cで入手できます。
タスク	プロジェクトに関連付けられたタスクの名前。
プロジェクト所有BU名	値を入力するための自由形式のテキストを表示します。
プロジェクト・タイプ名	値を入力するための自由形式のテキストを表示します。

考慮事項

これらの購買依頼関連の考慮事項について考えてみます。

1. 金額固有の承認ルールの場合は、次のいずれかを実行します:

   • 承認ポリシーがビジネス・ユニット間で異なる場合は、購買依頼発行ビジネス・ユニットの機能通貨で承認金額を指定する条件に、購買依頼発行ビジネス・ユニットを含めます(オプションで機能通貨を含めます)。

     購買依頼承認金額が500以下で、機能通貨がUSDで、販売先BUがVision USAの場合。

   • または、承認限度が標準通貨で強制される場合は、通貨換算レート機能を使用します。 文書の金額通貨を承認ルールの通貨に換算するための、通貨ベースのタイプのユーザー定義属性を作成します。

2. 使用中の関係者(使用不可でない)ごとに、文書が承認のために送信されるときに少なくとも1つのルールを適用する必要があります。 文書属性が関係者内の既存のルールの条件を満たさない場合、AMXは自動承認しません。

   • 例1 : ヘッダー階層関係者を使用して、次の条件を持つ購買依頼金額に基づいてルールを設定します:

     • 500 USDを超える1000 USD未満の購買依頼には1レベルが必要です。

     • 1000 USD以上、2000 USD未満の購買依頼には2レベルが必要です。

     • 2000 USD以上の購買依頼には3レベルが必要です。

       つまり、500 USD以下の購買依頼には承認は必要ありません。 この場合、購買依頼を自動的に承認するルールを作成する必要があります。

     • 例2: 購買依頼明細のカテゴリに基づいてルールを設定するには、承認前ヘッダー・コンセンサス関係者を使用します。 次の2つのカテゴリについて、追加の承認がルーティングされる必要があります:

       • IT機器

       • オフィス家具

         この参加者の残りのカテゴリを自動的に承認するには、ルールを追加する必要があります。

     • 例3: 購買依頼明細のスマート・フォームに基づいてルールを設定するには、承認前ヘッダー・コンセンサス関係者を使用します。 次のスマート・フォームに対してルーティングされる追加の承認が必要です:

       作業Visaリクエスト

       条件: スマート・フォームが空白でなく、スマート・フォームが作業Visaリクエストと等しい場合。

       • 属性が空でないことを確認する条件を追加してください。 これは、値を含まないドキュメント内の属性を使用するすべてのルールに適用されます。

         すべての購買依頼明細にスマート・フォームが関連付けられているわけではないため、次の自動承認ルールを追加する必要があります:

         (スマート・フォームが空白ではなく、Work Visa Requestと等しくない)場合、またはスマート・フォームが空白の場合。

       • 例4: 第1ステージ承認のシリアル承認関係者を使用して、サプライヤ登録リクエストの税組織タイプに基づいてルールを設定します。

         条件: 税組織タイプが個別の場合。

         承認が正常に生成されるように、次のことを実行できます:

         1. 少なくとも1つの条件がtrueと予想されるORセパレータを使用して、複数のルール条件を作成します。

         2. 同じ参加者に別のルールを追加して、Tax Organization Type(税組織タイプ)がIndividual(個人)でないサプライヤ登録リクエストをカバーするようにします。すべての登録がこの値を持つわけではありません。

       • 例5 : 第1ステージ承認のシリアル承認関係者を使用して、サプライヤ登録で次の条件を持つ承認ルールを設定します:

         条件: 銀行口座国がアメリカの場合。

         この条件がtrueに評価されるには、登録リクエストに銀行口座詳細が入力され、銀行口座国が米国である必要があります。 登録リクエストに銀行口座情報が含まれていない場合、このルールは適用されません。

         承認が正常に生成されるようにするには、銀行口座情報が存在しない場合に適用される条件を含む別のルールが参加者に含まれている必要があります(銀行口座入力がいいえの場合)。

         これは、これらのディメンションの属性を使用して作成された承認ルールに適用されます: 連絡先、住所、事業分類、銀行口座、製品およびサービス・カテゴリ。 次の属性は、これらのディメンションの属性がルール評価で使用される場合に、各子エンティティの登録に関する情報が提供されないケースを処理するために使用する必要があります。

         1. 担当者の場合は、入力した担当者を使用します。

         2. 住所には、住所入力済を使用します。

         3. Business Classifications(事業分類)で、Business Classification Entered(事業分類入力済)を使用します。

         4. 銀行口座の場合は、銀行口座入力済を使用します。

         5. Product and Services Category(製品およびサービス・カテゴリ)に、Product and Services Category Entered(製品およびサービス・カテゴリ入力済)を使用します。

       • シリアルでルーティングされた関係者内で戻されたすべての承認者は、順序付けされ、順番に通知されます。

         たとえば、2つの明細がある購買依頼のヘッダー階層関係者では、次のルールがtrueと評価されます:

         明細1はルール1を満たします: 購買依頼明細がITカテゴリに属し、金額が500 USD未満の場合は、ITマネージャおよびITディレクタからの承認が必要です。

         明細2はルール2を満たします: 購買依頼明細が施設カテゴリに属し、金額が1500 USDを超える場合は、施設マネージャおよび施設責任管理者からの承認が必要です。

         この場合、ヘッダー階層関係者内では、承認は次の順序でルーティングされます:

         • ITマネージャ

         • ITディレクタ

         • 施設マネージャ

         • 施設ディレクタ

         組織で複数の階層パスに承認のために文書を同時にルーティングする必要がある場合は、複数のシリアル・ベースの関係者を使用する必要があります。 ヘッダー・ステージでヘッダー階層、ヘッダー階層2およびヘッダー階層3の関係者を使用して、組織の要件に基づいてルールを保守できます。

     • 最初の応答者が獲得した投票制度を持つ参加者内の1つのルールのみが、特定の文書についてtrueと評価される必要があります。

       最初のレスポンダ獲得関係者内で複数のルールが適用される場合、各ルールによって返される承認者はグループ化され、このグループからの1つのレスポンスのみが承認結果を決定します。

       1. たとえば、Header First Responder Wins参加者では、次のようになります:

          1. 次のルールが定義されます:

             • 購買依頼にITカテゴリからの明細が含まれる場合、ルール1にはIT承認グループの承認者が含まれます。

             • 購買依頼に法的カテゴリからの明細が含まれる場合、ルール2には法的承認グループの承認者が含まれます。

          2. 両方の条件が満たされ、2つのルールがトリガーされると、IT承認グループと法的承認グループの両方から承認者が戻されます。 ただし、IT承認グループの承認者が購買依頼を承認すると、この参加者は承認済とみなされ、法的承認グループからの処理は必要ありません。

       2. 関係者内で少なくとも1つのルールを適用する必要がある要件を満たすために、最初の応答者が獲得した関係者の承認が不要な条件に空の承認グループ・ルールを使用するルールを設定できます。 このオプションは、承認を必要とするルールと承認を必要としないルールの両方を満たすオブジェクトが文書に含まれている場合に、関係者が自動承認されないようにします。 監督階層ベースの自動承認オプションを使用すると、関係者に対する承認レスポンスとして処理されるため、実際に承認を必要とする他のルールをバイパスします。

          空の承認グループを使用する自動承認ルール

          • ルールの作成時にはルールの選択が常に適用されます

          • 処理タイプ=承認必須

          • 使用経路=承認グループ

          • 承認グループ=承認なし

          • このグループは、参加者が指定されることなく、BPMワークリスト・アプリケーションの「承認グループ」タブで作成する必要があります。

          • グループが承認者を戻さなかった場合に自動的に承認=選択

       組織で承認を独立して提供するために異なる承認者グループが必要な場合は、各ステージで最初の応答者が獲得した関係者を配置できます。

       前述の同じ例を使用します。

       1. ルール1は、少なくとも1つのルールがtrueに評価される必要がある要件を満たすための自動承認ルールとともに、承認前ヘッダー(最初の応答者が獲得)参加者に追加できます。

       2. ルール2は、少なくとも1つのルールがtrueに評価される必要がある要件を満たすための自動承認ルールとともに、ヘッダー・ステージ(最初の応答者が獲得)参加者に追加できます。

       3. 承認前ヘッダー(最初のレスポンス者が獲得)参加者のレスポンスは、IT承認グループから要求されます。 また、Header Stage First Responder Wins(ヘッダー・ステージ第1レスポンス者が獲得)参加者と別のレスポンスがLegal Approval Group(法的承認グループ)から求められます。

3. 承認済購買依頼からの明細レベルの取下げがサポートされています。

   例: 承認済購買依頼(POにはない)には4つの明細があります。 作成者として、明細2を選択し、その明細を取り下げます。 次に、明細2を変更し、承認のために再送信します。 定義された承認ルールに基づいて、明細2のみが再承認のためにルーティングされます。 その他のすべての行は現在の状態のままになります。

4. 「購買依頼発行ビジネス機能の構成」ページには、ユーザーが定義できる3つの承認関連コントロールがあります:

   • アクティブな承認プロセス中に行われた変更の再承認が必要: これにより、承認者が購買依頼を変更するたびに、購買依頼を再承認のために送り返す必要があるかどうかが制御されます。 デフォルトでは選択解除されています。

     例: 承認者が購買依頼明細を変更して購買依頼を発行すると、かつこのチェック・ボックスが選択されている場合は、新しい承認プロセスが開始されます。

   • バイヤー変更明細には承認が必要です: これは、バイヤーが変更した明細を承認のために発行するかどうかを制御します。 デフォルトでは選択解除されています。

     例: 購買依頼が承認され、POが作成される前に、バイヤーは明細を変更できます。 このチェック・ボックスが選択されていて、新規明細の合計金額が当初明細の金額と等しくない場合、変更された明細は購買依頼承認ルールに基づいて再承認のためにルーティングされます。

   • 承認者上書き使用可能: これは、購買依頼作成フローに「上書き承認者」フィールドを表示するかどうかを制御します。

5. 組織内のすべての購買依頼を承認のためにコスト・センター・マネージャにルーティングする必要がある場合、コスト・センター・マネージャ・ベースの承認は、次の条件を使用して設定できます:

   コスト・センター・マネージャが空白でない場合、ユーザー・タイプがコスト・センター・マネージャである単一ユーザーを使用してルーティング

   コスト・センター・マネージャは、設定マネージャの「部門の管理」ページで設定します。

6. 自動承認ルールの場合、トランザクションは、タスク作成者(作成者)ではなく、内部APPIDユーザー(アプリケーション開発フレームワーク・アプリケーション)を使用して承認されます。

7. 承認ルール優先度: 購買依頼の管理承認UIが、承認ルールの優先度をサポートするように拡張されました。 上位優先度ルールからの承認者に、下位優先度ルールから承認者の前に通知されます。 次の値がサポートされている優先度です: Highest, Higher, High, Medium, Low, Lower, Lowest. 中がデフォルトの優先度です。

   優先順位の適用方法は?

   • 承認エンジンは、トランザクションについて真と評価される条件を含むルールに基づいて、承認者のリストを決定します。

   • 承認者のリストは優先度順に並べられるため、優先度が最も高い承認者は、通知を先に受け取ります。

   • 同じ優先度を持つルールの承認者に、ランダムな順序で通知されます。

8. 送信者(タスク作成者)が承認リストに含まれている場合にトランザクションの自己承認を防止するには、次のタスク構成プロパティをBPMで設定する必要があります:

   承認リストの作成者をスキップ= YこのオプションがYに設定され、購買依頼作成者/購買担当が承認者の1人である場合、タスクは作成者のタスク割当をスキップするチェーン内の次の承認者にルーティングされます。 単一の承認者シナリオでは、作成者のタスク割当をスキップすると、トランザクションを承認する別の承認者がチェーン(または自動承認ルール)に存在しないかぎり、タスクの結果が否認に設定されます。 または、作成者のマネージャに割当フラグをYに設定して、作成者をHCMで設定したマネージャに置き換えることができます。

   ノート:

   アプリケーション・ロールまたはポジション階層ベースのルーティングを使用する場合、作成者のタスク割当はスキップされません。