ToolTech サンプル・ストアのトラブルシューティング (Business Edition)

このファイルでは、ToolTech サンプル・ストアをセットアップする際に生じる可能性のある一般的事項を記載しています。 詳細については、関連トピックのオンライン・ヘルプを参照するか、またはヘルプ・デスクに連絡してください。

2 回目の発行の際に ToolTech 発行が失敗する。

同じ組織を使用して ToolTech ストアが 2 度発行される場合、2 回目の発行は失敗します。 これを避けるため、以下のようにしてください。

1. 管理コンソールを使用して新しい組織を作成する。 
2. SAR ファイルを作成する際、ストア・サービスで、この新しい組織をセラー組織として使用する。

その上で、発行を行ってください。


注: バイヤー組織はストアの発行には使用できません。 ToolTech ストアを発行する前に、ストア所有者として用いる新規組織を作成することをお勧めします。 デフォルトの組織を発行に使用することはお勧めできません。

LDAP を構成する際に登録が失敗する。

ToolTech ストアに新規顧客を登録する際、 WebSphere Commerce が LDAP と共に実行されるように構成されている場合には登録は失敗します。 これは、バイヤー組織 A およびバイヤー組織 B がまだ LDAP にマイグレーションされていないためです。 これを避けるには、以下のようにしてください。

1. ストア内の新規顧客を登録する前に、組織 A および組織 B を LDAP にマイグレーションする。
2. LDAP レジストリーと WebSphere Commerce とを手動で同期する。

バイヤー管理者役割用のバイヤー承認 GUI へのリンクが見えない。

バイヤー承認はバイヤー承認グループの設定によりストア内で使用可能になり、 ユーザーにはバイヤー (購買サイド) およびバイヤー管理者の役割が割り当てられます。 しかしストアへのログインの際、バイヤー承認 GUI へのリンクが見えません。 これを避けるには、以下のようにします。

  1. ストア用の WebSphere Commerce キャッシングをオフにする。 キャッシュを使って実行していた場合、 WebSphere Commerce および WebSphere Application Server (WAS) のキャッシュ・ディレクトリーをクリーンアップする必要がある場合があります。
  2. 顧客にバイヤー承認およびバイヤー (購買サイド) の役割を割り当てる。

これで、バイヤー承認 GUI へのリンクを見ることができるでしょう。

注: オーダー承認に関しては、 顧客はバイヤー (購買サイド) およびバイヤー承認者の役割を有している必要があります。

バイヤーの承認保留が、バイヤー承認 GUI で見えない。

バイヤー承認 GUI を呼び出し、 「Approval (承認)」リンクをクリックする際、 顧客はバイヤー組織 A およびバイヤー組織 B の下で登録されているにもかかわらず、 バイヤーの承認保留がありません。これを避けるには、以下のようにします。

  1. 他のユーザーを承認するために使用しているユーザーに割り当てられている役割を検査する。
  2. 承認者にバイヤー (購買サイド) およびバイヤー管理者役割が割り当てられていることを確認する。

注: オーダー承認に関しては、 顧客はバイヤー (購買サイド) およびバイヤー承認者の役割を有している必要があります。

オーダーを分割する際に次のメッセージが表示される: "Purchase order .. is not a predefined purchase order..." (購入オーダーが事前定義された購入オーダーではない...)

購入オーダー (PO) 番号が分割オーダーのために使用される場合、エラーが生じ、そのオーダーは完了できません。 これを避けるには、以下のようにします。

  1. 個々の PO 番号を 1 度しか使用していないことを確認する。 この番号を複数回使用するとエラーが生じます。
  2. 固有の PO の代わりに、B1234567 のようなブランケット PO を使用する。

注: ブランケット PO は 2345 の下で購入されたオーダー・アイテムにのみ適用されます。

エディターから作成された配送モードを契約に組み込めない。

新規に作成された配送モードをビジネス関係管理 (BRM) ツールに表示するには、 配送モード、および配送モード用のポリシーを配送ノートブックで作成する必要があります。 契約がポリシーを確実に受け入れるようにするため、配送モード用のポリシーを手動で作成できます。

注: 配送ノートブックでは、新規配送モードの作成のみ行えます。

商品の除外されたサブカテゴリーがストアに依然として表示されている。

BRM 内の契約からサブカテゴリーを除外する場合、 その除外したサブカテゴリーがストア内に依然として表示されます。 サブカテゴリーをクリックすると、商品は表示されません。

少量のサブセットの商品のみを許可するよう契約を設定したにもかかわらず、 すべての商品のオーダーが可能。

指定された契約の販売に含めるように 1 つのカテゴリーだけを選択しても、 ストア・ページが表示される際に、すべてのカテゴリーおよび商品が依然として購入可能でオーダーできます。 これを避けるには、以下のようにします。

  1. バイヤー組織 A の使用を避ける。 なぜなら、それはすべての商品がストア内で見えるようにするデフォルトの契約をサポートしているからです。 より制限の多い契約は組織 A に影響を与えません。
  2. バイヤー組織 B を使用して、このプロセスを繰り返す。

バイヤー組織 A のビジネス関係管理 (BRM) GUI には契約が 1 つあるが、 ストアには 2 つの契約が表示される。

契約がバイヤー組織 A のアカウントを通してアクセスされる場合、 バイヤー組織 A のアカウントはストアに 1 つの契約を表示しますが、 バイヤー組織 A の下で登録された顧客は 2 つの契約として 1234 (デフォルトの契約) および 2345 を 「アイテムの表示」ページに見ることができます。

バイヤー組織 A 自体は 1 つの契約を有していますが、デフォルトの契約のサポートが可能です。  GUI には、この組織に属している契約だけが表示されます。

バイヤー承認者 GUI からログアウトした後に、バイヤー承認者が ToolTech からログオフする。

バイヤー承認者が承認を保留している顧客を承認した後、GUI をログアウトし、ストアは停止します。 これを回避するには、以下のようにします。

  1. 再びバイヤー承認者としてログインする。
  2. 「Buyer Approval GUI (バイヤー承認 GUI)」ウィンドウがクローズする際、ログアウトしない。

注: ストアが停止する理由は、 cookie が 2 つのブラウザーのウィンドウ間で共用されるためです。 立ち上げた GUI からログアウトする場合、オリジナルのウィンドウからも自動的にログアウトします。

「Request for Quotation (RFQ) (見積要求 (RFQ))」GUI をクリックすると、 汎用アプリケーション・エラーが発生する。

RFQ リンクはすべての顧客からアクセス可能なのではありません。 このリンクがアクセス可能になる前に、特定の役割を割り当てられることが必要です。 このエラーを避けるには、以下のようにします。

  1. ユーザーに割り当てられた役割を検査する。 RFQ GUI にアクセスするには、バイヤー (購買サイド) 役割が割り当てられていること、 および Internet Explorer 5.5 が必要です。 
  2. 各ユーザーが 1 つの組織にのみ属していることを確認する。
  3. アクセス制御ポリシーを変更し、ユーザー・グループが組織の有効範囲から外れるようにする。 これは、バイヤー役割を果たす人すべてが RFQ を作成できることを意味します。

その作業を行うには:

  1. 管理コンソールに進む。
  2. 「アクセス管理」をクリックする。
  3. 「Polices (ポリシー)」をクリックする。
  4. 下記のポリシーを選択する。
    RFQBuyersForOrgExecuteRFQCreateCommandsOnStoreEntityDataResourceGroup
  5. 「変更」をクリックする。
  6. ポリシー・ユーザー・グループを RFQ バイヤーに変更する。
  7. レジストリーをリフレッシュするか、または WebSphere Commerce を再始動する。

注: RFQ に関連するその他の作業については、以下の関連リンクを参照してください。

関連概念

関連参照

関連タスク

IBM 著作権