私はここに Websphere commerce 7 Fp 5 Aurora B2B を持っています。これは、組織、契約、および価格表を使用して、各「ストア」組織を 3 つ購入するように制限する最大注文数量を制限しているため、十分に回ることができます。ほとんどの人が最大 3、より良い店が最大 5、いくつかの本当に良い店が最大数量 10 の 3 セットの資格があります。
したがって、割り当てについて心配する必要はありません。これらのルールにより、すべてのストアが資格に基づいて購入できます。必要以上にカートに入れようとすると、「割り当て制限を超える注文をリクエストしています。リクエストされた数量を変更してください。」というメッセージが表示されます。これがどこから来たのかわかりません。
一部のユーザーは、支払い時のチェックアウトで選択された 5 店舗以上で購入します。これにより、店舗の所有者は、追跡するために多数のログインを行う必要がなくなります.
最近、注文管理を開始しました。これをマルチカートと呼んでいます。これにより、店舗の所有者は、注文管理に移動して新しい注文を作成することで、複数のカートを作成できるようになります。これにより、店舗の所有者は、CSR チームに電話したり電子メールを送信したりすることなく、購入したり、支払ったり、受け取ったりするものをより簡単に管理できるようになります。
しかし今、一部の店舗がマルチカートを利用して、許可されている MAX 数量を超えて購入していることに気付きました。それほど悪くはありませんが、彼らは顧客ごとにすべてのものを購入しており、他のすべての店舗は、シェアを獲得できなかったために電話をかけ、不平を言っています。それは本当に公平ではありません。
注文履歴と保留中の注文の SQL チェックを追加するさまざまな場所を考えていました。これが私が思いついたものです。
ATP - 在庫チェック プロ - 顧客、SKU、権限、およびその他すべてのほとんどがここで行われるため、最高の場所です。真正面です。短所 - 配送先がないため、定期的に変更される可能性のあるずさんなビジネス ロジックをリードする例外として、複数の店舗を持つ人を追加する必要があります。
OrderItemAddCmdImpl とオーバーロード ExtendOrderItemProcessCmd Pro - 出荷先の選択を前面に出し、ここですべてを制御します。短所 - 特定のオーバーヘッドがそれを気に入るとは限りません。
チェックアウト時にプロ - これにもすべてが含まれます コン - すべての支払い処理のためにこれを予約したい. 注文明細を読み、SKU でエラーをキックバックするのは少し面倒です。
ERP に例外を処理してもらいます - Con - すべての注文が完全に出荷されるように設定されていることに気付きました。これを変更する必要があり、クレジットに保持されている金額よりも少ない請求に対して追加のクレジット カードのペナルティがあるため、実際には変更したくありません。
それで、質問は、追加の長所と短所についてどう思いますか? もっと意味のある、私が見逃している他の場所はありますか？