Skip to main content
Join the Agentforce Hackathon on Nov. 18-19 to compete for a $20,000 Grand Prize. Sign up now. Terms apply.

税金、フルフィルメント、データインポートを構成する

学習の目的

この単元を完了すると、次のことができるようになります。

  • Order Management で総税額表示を構成するために実行する必要がある手順を挙げる。
  • 3 つの履行種別カテゴリを挙げる。
  • 「履行注文容量を保有」がどのように機能するかを説明する。
  • 状況カテゴリが履行注文レコードの状況とどのように関連するのか説明する。
  • 注文レコードをインポートする方法を説明する。

設定を構成する

注文管理は、履行処理機能と価格、税金、注文状況データと緊密に統合されています。つまり、さらに設定する必要があるということです。そこで、システム管理者の Linda Rosenberg は、Order Management でこうした機能を構成する方法を学習します。

税金表示を設定する

Linda は、地域で採用されている課税種別 (純税額、総税額) によって組織に表示される価格や税金が異なるようにしたいと考えています。まず、次の点を認識しておく必要があります。

課税種別

価格と税金の表示

正味税額の地域でビジネスを行っている場合

正味 

消費税と価格

個別

追加の設定は必要ありません。

総額

付加価値税 (VAT)

合計

価格と税金をまとめた金額が表示されるように組織のページレイアウトを設定します。

Linda の組織ではマルチ通貨が有効になっているため、標準ユーザープロフィールをコピーして、総税額の地域のサービスエージェント用のユーザープロフィールを作成します。次に、正味税額項目の代わりに総税額項目を使用するページレイアウトを作成し、新しいプロファイルに割り当てます。この手順は次のとおりです。

  1. [Setup (設定)] の [Quick Find (クイック検索)] ボックスに Object Manager (オブジェクトマネージャー) と入力し、[Object Manager (オブジェクトマネージャー)] を選択します。
    • 価格が表示される各オブジェクトで、価格と税金の金額をまとめた総税額項目を使用するページレイアウトを作成します。
  1. [Setup (設定)] の [Quick Find (クイック検索)] ボックスに Profiles (プロファイル) と入力し、[Profiles (プロファイル)] を選択します。
    • 組織が複数の通貨に対応している場合、標準ユーザープロファイルをコピーします。新しいプロファイルには、総税額を処理するユーザーに適用されることを示す名前を付けます。
    • 総税額を使用する地域でのみビジネスを行っている場合は、標準ユーザープロファイルを編集します。
    • 組織が複数の通貨に対応している場合、新しいプロファイルを編集します。
    • 総税額ページレイアウトをユーザープロファイルに割り当てます。
  1. 1 個以上の注文概要レコードを作成します。
  2. Salesforce Order Management で、[注文概要] レコード詳細ページを開きます。
    • そのページにある [設定] メニューから、[編集ページ] を選択します。
    • [合計] コンポーネントの [注文の総税額の項目] セクションを設定します。
    • ページを保存してアクティブ化します。

履行を設定する

注文プロセスの履行部分では、注文を買い物客にどのように届けるかが処理されます。これには、常に場所と状況が関係します。Order Management に付属のサンプル履行パッケージにはフロー、プロセス、Apex クラスが含まれ、Flow Builder の手順に従って履行を実装できます。

履行のカテゴリと種別

履行種別は、倉庫からやオンライン上など、注文がどのように履行されるかを示します。注文管理では、固定の履行種別カテゴリにそれぞれ割り当てられた柔軟な履行種別でこれを処理します。注文管理には、デフォルトの履行種別が用意されており、さらに追加することができます。履行注文に割り当てられた履行種別は、注文管理においてその注文の商品に使用される履行方法を示します。カテゴリと種別は次のとおりです。

履行種別カテゴリ

 デフォルトの履行種別

物理的

  • 倉庫
  • 小売店
  • 店舗受け取り

直送

  • サプライヤー

デジタル

  • ダウンロード
  • メール

履行種別カテゴリを変更することはできませんが、各履行種別を履行種別カテゴリに関連付けている場合に限り、それぞれをカスタマイズできます。履行種別をカスタマイズするには、履行注文オブジェクトの [種別] 項目の選択リスト値を編集します。

履行場所

商品は一体どこから取得されるのでしょうか? それが履行場所です。Linda は [倉庫] や [小売店] など一連の履行場所種別を定義して、場所オブジェクトの [場所種別] 選択リストに追加します。次に、各履行場所を表す場所レコードを作成します。

また、ルーティングロジックに優先度を使用して、場所のランキングシステムを作成することもできます。場所オブジェクトの [優先度] 項目選択リストに値を追加し、各場所に値を割り当てるという方法でランキングを設定します。この処理は自動的に実行されません。

履行注文容量を定義することで、その場所に割り当てる履行注文数を制限できます。場所に割り当て可能な履行注文数はいくつでしょうか? 場所オブジェクトには、履行注文容量を使用するための次の 3 つの項目があります。

場所オブジェクト項目

説明

履行注文容量を追跡

場所の容量が追跡されているかどうか。

履行注文容量

ユーザー定義の期間ごとに場所に割り当てることができる履行注文の最大数。

この値が null の場合、ロケーションの容量は無制限になります。

割り当て済み履行注文数

現在場所に割り当てられている履行注文の数。

最大容量に関連する期間を定義するには、この値を特定の間隔でリセットします。たとえば、1 日あたりの容量を追跡するには、各場所のタイムゾーンの午前 0 時に、この値を 0 に設定する自動ジョブを実行します。

各場所から何を出荷できるかを把握しておくことは、時間どおりに配送したり、買い物客の満足度を高めたりする上で重要です。注文管理では、次の表に示すように、履行注文容量データに対するアクションを介して、場所の容量が処理されます。注文管理では、場所の履行注文容量を保持、確認、解放、取得することができます。

リソース/アクション

説明

履行注文容量を保持する

ある場所に履行注文を割り当てるには、その場所で履行注文の容量を保持します。その場所に空き容量がない場合はエラーが返されます。空き容量とは、その場所の履行注文容量から、保持されている容量と割り当てられた履行注文の合計を差し引いた容量です。

保持されている履行注文容量を確認する

ある場所に履行注文を割り当てる場合は、その場所で保持されている履行注文容量を確認します。

これにより、場所の割り当て済み履行注文数が増加し、保持済みの容量が減少します。

履行注文容量を解放する

ある場所で履行注文容量を保持していたが、その場所に履行注文を割り当てないことを決定した場合、保持していた容量を解放します。

これにより、割り当て済み履行注文数は増加せずに、場所で保持されている容量が減少します。

履行注文容量値を取得する

この値を取得すると、ロケーションの最大容量、割り当て済み履行注文数、および保持済みの容量が返されます。保持済みの数量は Location (場所) オブジェクトの項目にはないため、これが唯一の取得方法となります。

割り当て済み履行注文数をリセットしても、未割り当ての履行注文に対して保持されている容量は削除されません。保持されている容量を減らすには、保持されている容量を確認するか、解除する必要があります。

Salesforce Omnichannel Inventory を使用して在庫場所を管理する場合は、場所グループを作成して場所をそのグループに割り当てます。Omnichannel Inventory の実装に含まれる場所と場所グループについて、ShouldSyncWithOci 項目を true に設定します。

状況と状況カテゴリ

注文管理では、状況のカテゴリを使用して、注文がワークフローを進んでいく際にその状況を追跡します。注文管理によって履行注文レコードの状況が設定されると、状況カテゴリも設定されます。

状況カテゴリを変更することはできません。状況カテゴリは固定されています。ただし、状況については、カテゴリに関連付けていればカスタマイズできます。カスタムプロセスでレコードの状況カテゴリを使用している場合は、状況カテゴリが固定されていることが重要になります。

履行注文の状況カテゴリにより、注文商品概要の数量項目がその履行注文商品に関連付けられます。たとえば、履行注文レコードの状況が [割り当て済み] または [梱包] である場合、状況カテゴリは [履行中] になります。ビジネスプロセスに基づいて、次のような注文状況を追加できます。

  • 承認済み
  • 履行を待機中
  • 遅延

では、これは注文管理とどのように連動するのでしょうか? 注文管理は、次の表に示すように、複数のオブジェクト種別と連動します。各オブジェクト種別には固定された状況カテゴリがあり、各状況カテゴリは 1 つ以上の状況と関連付けられています。標準の設定は次のとおりです。

オブジェクト種別

状況のカテゴリ

デフォルトの状況

履行注文

ドラフト

  • ドラフト

アクティブ化済み

  • アクティブ化済み

履行中

  • 担当者
  • 梱包

完了

  • 履行済み

キャンセル

  • キャンセル

注文

ドラフト

  • ドラフト

アクティブ化済み

  • アクティブ化済み

注文概要

N/A

  • 作成済み

プロセス例外  

有効

  • 新規
  • トリアージ済み

無効 

  • 無視
  • 一時停止
  • 取り消し済み

解決済み

  • 解決済み

解決済み

アクティブ化済み

  • アクティブ化済み
  • 送信済み

キャンセル

  • キャンセル

完了

  • 完了

ドラフト

  • ドラフト

注文概要オブジェクトには、[状況のカテゴリ] 項目ではなく [状況] 項目があります。注文概要状況は、注文管理の標準機能では使用されませんが、カスタムビジネスプロセスを実装するために使用できます。注文概要状況を追加する場合は、注文状況と一致するように設定することをお勧めします。

過去の注文レコードをインポートする

通常は、高スケール注文から注文データが取り込まれ、注文概要が自動的に作成されますが、ユーザーが保留中の注文概要を手動でインポートして、注文概要の作成をトリガーすることができます。

過去の注文レコードや非標準の注文レコードをインポートする必要がある場合、Linda は Bulk API または複合 API を介してこれを行い、インポートされた注文レコードで実行する [注文概要を作成] フローを設定します。

API は開発者ツールで開発者の助けが必要なため、まずは Flow Builder を使ってみることにします。ここで重要な点は、OrderSummary 注文レコードを直接作成せず、Flow Builder を使用するか、API をコールすることです。注文処理を自動化すれば、時間を節約し、データのエラーを減らすことができます。大量の注文データをインポートするために、Linda は Bulk API 2.0 の使用についてデベロッパーに協力を依頼します。少量の注文データをインポートするときは、複合 REST API 要求を実行できます。

Order Management を Production (本番) 環境で使い始めた後、Linda は 参考のために過去の注文データをレガシーシステムからインポートできます。通常、サービスの対象外となった注文は、未管理注文としてインポートします。

次のステップ

この単元では、価格や税金の表示、フルフィルメント、注文ステータスを構成し、古い注文レコードや非標準の注文レコードをインポートする方法を学習しました。次は、支払処理の構成方法について説明します。

リソース

Salesforce ヘルプで Trailhead のフィードバックを共有してください。

Trailhead についての感想をお聞かせください。[Salesforce ヘルプ] サイトから新しいフィードバックフォームにいつでもアクセスできるようになりました。

詳細はこちら フィードバックの共有に進む