0

付与された報酬ポイントが負である編集済みの注文を送信すると(新しく処理された注文が元の注文よりも少ないため)、報酬履歴で、エントリの1つが最新のエントリより12時間早く進められます

値が正しく計算されているため、これによって合計報酬ポイントに悪影響が生じることはありません。

注文の編集モジュールがこれを行うことは実際には何もできません。注文を編集するために、モジュールは再注文とまったく同じことを行いますが、前の注文のアイテム、数量、日付を保存する新しいセッションも作成します。注文が行われ、増分IDです。ポイントの計算方法は、通常の計算時にこのセッションのチェックが行われることです。存在する場合は、ベース総計を取得し、それを$this->getReward()->getRateToPoints()->calculateToPoints()ポイントデルタから差し引きます。

チェックアウトで注文を処理すると、新しい注文が作成されますが、トランザクションIDは前の注文と同じです。インターネット販売はこのトランザクションIDを確認するため、編集する注文がわかるため、古い注文はキャンセルされます。同期スクリプトの次の実行中

そのすべてを考えると、報酬履歴で何かをすることは決してありません。報酬履歴エントリをプッシュした編集者の順序が常にプッシュされたわけではありません。100000040の順序で編集しましたが、100000042がプッシュされました。

注:支払いゲートウェイからのリクエスト/レスポンスxmlと比較するためのサンプルxmlを待っているため、現時点では注文に同じトランザクションIDが保存されていないことも指摘しておく必要があります。そのため、注文を1回処理する方法はありません。何らかの方法で別の注文に関連付けられています


次のコードはから取られています、それはとEnterprise_Reward_Model_Action_OrderExtra::getPointsの間の場所です$pointsDelta = $this->getReward()->getRateToPoints()->calculateToPoints((float)$monetaryAmount);return $pointsDelta;

$editOrder = Mage::getModel('core/session')->getData('editorder');

    if(!is_null($editOrder))
    {
        $readConnection = Mage::getSingleton('core/resource')->getConnection('core_read');
        $result = $readConnection->fetchAll("
                SELECT sfo.entity_id FROM sales_flat_order AS sfo
                    WHERE sfo.increment_id = ?
                LIMIT 1
            ",$editOrder['original_order']);
        $order = Mage::getModel('sales/order')->load($result[0]['entity_id']);
        $orderData = $order->getData();
        $previousOrderMonetaryAmount = (($orderData['base_grand_total'] - $orderData['base_shipping_amount']) - $orderData['base_tax_amount']);

        $pointsDelta = $pointsDelta - $this->getReward()->getRateToPoints()->calculateToPoints((float)$previousOrderMonetaryAmount);
    }

ここに画像の説明を入力してください

上は何が起こっているかのスナップショットです、上は注文が編集され処理される前の報酬履歴を示しています、下はその後に起こっていることです(#100000049の場合は何も起こらなかったので、グリッチが表示されるようにもう一度やり直さなければなりませんでした)

#100000044のアイテムは、注文番号100000048とは完全に異なります。注文番号100000046は、ポイントのデルタが0の場合(ポイントが加算/減算されないことを意味します)、表示されません(これは良いことです)。

負の値を持つすべての注文は、正の値を持つが編集中に一部のアイテムが削除されてカートの合計が減少した編集済みの注文が処理されます(ゲートウェイでは、これにより顧客に返金されるため、許可されるべきではないことは理にかなっています返金されたポイントを獲得するため)

4

1 に答える 1

0

問題は、magento自体に関係することです。これは、magentoのクリーンビルドに$pointsDelta = $pointsDelta - 100000、まったく同じ問題の結果を使用して、常に負の量の順序にすることを強制することです。ただし、Magentoがそれをバグと見なすかどうかはわかりませんが、発見する唯一の方法です。それはMagentoのカスタマイズによるものですが、私はそれを報告します

于 2013-03-18T05:47:30.750 に答える