Magento Grand Total bez podatków w wersji 1.9 z PHP7

Pracujemy w wersji 1.9 & php7; wykryłem ten problem z podejrzeniem oszustwa PayPal (z powodu różnicy kwoty).

Wszystkie poprawne w interfejsie użytkownika (obowiązują podatki); ale w kasie i obliczeniach magento używa ogólnej sumy bez podatków.

Rzeczywiste obliczenie złego zamówienia:

Cena produktu bez podatków + wysyłka z podatkami = całkowita kwota do zapłaty

Przełącz na php5 i obliczenia są prawidłowe.

Jakiś pomysł?

Dzięki!

Rozwiązanie

Stworzyłem moduł magento, aby rozwiązać problemy z obliczeniami sumy dla php7. W szczególności napotkałem problemy z tym, że podatki zostały dwukrotnie dodane do ogólnej sumy do zapłaty za pomocą modułu amazon na stronie kasy amazonpayments.

Kredyty

Odpowiedź udzielona przez archigrafix w tym poście ( /magento//a/97107/35665 ) rozwiązała moje problemy - jest to po prostu poprawka zapakowana w moduł.

Moduł:

https://github.com/hartmut-ltd/magento-php7-totals-fix

Naprawdę nie wiem, czy to w jakikolwiek sposób pomoże, ale coś do zbadania.

Możliwe, że Twoje collecttotalszamówienie na model zamawia się inaczej, a podatek jest zamawiany / nakładany po grand_total

Możesz sprawdzić, czy jest to problem w następujący sposób. (Uwaga: wymaga to dostosowania pliku podstawowego, aby uzyskać informacje o debugowaniu, nie próbuj tego na stronie na żywo!)

Edytuj metodę znajdującą się w:

Mage_Sales_Model_Quote_Address::collecttotals

i dodaj jedną linię do metody, co pozwoli ci wyświetlać modele podczas ich przetwarzania.

public function collectTotals()
    {
        Mage::dispatchEvent($this->_eventPrefix . '_collect_totals_before', array($this->_eventObject => $this));
        foreach ($this->getTotalCollector()->getCollectors() as $model) {
            mage::log($model->getCode()); // <===== ADD THIS LINE
            $model->collect($this);
        }
        Mage::dispatchEvent($this->_eventPrefix . '_collect_totals_after', array($this->_eventObject => $this));
        return $this;
    }

upewnij się, że rejestrowanie jest włączone.

ogonuj plik dziennika za pomocą konsoli: tail -f system.log

Odtwórz problem za pomocą interfejsu.

W dzienniku otrzymasz następujące wpisy (z wanilii 1.9.2.2 - możesz mieć inne wpisy)

2015-12-21T05:54:12+00:00 DEBUG (7): nominal
2015-12-21T05:54:12+00:00 DEBUG (7): subtotal
2015-12-21T05:54:12+00:00 DEBUG (7): msrp
2015-12-21T05:54:12+00:00 DEBUG (7): freeshipping
2015-12-21T05:54:12+00:00 DEBUG (7): tax_subtotal
2015-12-21T05:54:12+00:00 DEBUG (7): weee
2015-12-21T05:54:12+00:00 DEBUG (7): shipping
2015-12-21T05:54:12+00:00 DEBUG (7): tax_shipping
2015-12-21T05:54:12+00:00 DEBUG (7): discount
2015-12-21T05:54:12+00:00 DEBUG (7): tax
2015-12-21T05:54:12+00:00 DEBUG (7): grand_total

Zobaczysz, jak się powtarza, więc po prostu zobacz, gdzie zaczyna się i kończy, powinno być łatwo zobaczyć wzór

Zwróć uwagę na dwa ostatnie wpisy powyżej: Podatek występuje przed grand_total. to może być możliwe, to kolejność jest z walnięcie, a podatek jest wyświetlana po grand_total, więc nie będzie miał grand_total podatki stosowane.

EDYTOWAĆ:

Ok, więc nie widziałem, aby zadane pytanie faktycznie wskazywało na sortowanie przedmiotów kolekcjonerskich jako problem. Podejrzewałem, że to może być problem, ale sam tego nie testowałem w PHP7

Jest rozwiązanie, ale nie jest zbyt miłe. Każde nowe rozszerzenie umieszczone w sklepie, które wstawia modele do kolektora, musiałoby zostać odnotowane i dodatkowo dodane do sortowania, w przeciwnym razie mogłoby pójść jeszcze bardziej źle. W przyszłości może to być problem z konserwacją.

Po prostu wymuś porządek sortowania, umieszczając określony <sort_order> element w konfiguracji sum. Możesz to zrobić za pomocą własnego rozszerzenia, które miałoby tylko config.xml, w którym określasz kolejność dla każdego kolektora.

w config.xml, mają dyrektywę jako taką:

<sales>
   <quote>
      <totals>
         <nominal>
           <sort_order>100</sort_order>
        </nominal>
        <subtotal>
           <sort_order>200</sort_order>
        </subtotal>
        <msrp>
           <sort_order>300</sort_order>
        </msrp>
        <freeshipping>
           <sort_order>400</sort_order>
        </freeshipping>

        ......
        insert each collector model with a sort directive
        ......

     </totals>
   </quote>

Użyj dużych odstępów między każdą dyrektywą sortowania, aby zapewnić miejsce na wstawienie dodatkowych w przyszłości.

Jak wspomniano, niezbyt elegancki, ale może rozwiązać twój bezpośredni problem.

Należy również pamiętać, że w systemie znajdują się inne dyrektywy dotyczące kolektorów, więc mogą one również być błędne / wymagać dostosowania

Sprawdź podstawowe rozszerzenie config.xml i wyszukaj <totals>

Znajdziesz tam:

<order_invoice>
<order_creditmemo>
<pdf>

Mogą być inne w innych rozszerzeniach, niezależnie od tego, czy jest to rdzeń / strona trzecia

Mam nadzieję, że to pomaga.

PS: Nie testowałem tego w PHP7. Wiem, że umieszczenie dyrektywy sort_order działa pod php5.x

Na Magento 1.6.2 i PHP 7.0.2 rozwiązałem to w ten sposób:

1 - Najpierw utworzono lokalny config.xml: Skopiowano /app/code/core/Mage/Sales/etc/config.xml do /app/code/local/Mage/Sales/etc/config.xml

2 - Zmieniłem to w ten sposób

Teraz oblicza poprawnie: