Rozbieżność Liczenia Wartości Zamówienia Między Prestą, A Systemem Sprzedaży/erp

[PrestaShark]

Hej.

Czy spotkaliście się z rozbieżnościami liczenia wartości zamówienia między Prestą, a jakimś system sprzedaży/ERP?

 

Kiedy zamówienie wpada ze sklepu jest wprowadzane ręcznie do ERP.

Problem pojawia się w momencie kiedy zamówienie jest niskiej wartości i doliczane są koszty dostawy

Łączna wartość zamówienia w sklepie 477,87

Łączna wartość zamówienia w ERP 478.37 (równe 0,50gr więcej...)

wszystko licząc te same pozycje

 

Kiedy zamówienie przekracza 500zł i koszty transportu nie są liczone w sklepie to wartości zamówienia są równe między sklepem, a tym co odzwierciedla ERP na fakturze.

 

Czy Presta kalkuluje koszty dostawy oraz podatek niezależnie poza produktami?

ERP liczy dostawę jak każdą inną pozycję w liście. Sumuje wszystko i mnoży przez 1.23 podatku.

[() Maciej ()]

Masz prawdopodobnie źle przeliczone ceny dostawy. U mnie problem ten występuje tylko na produktach, ale różnice w cenie są w granicy 1 gr.

Różnica bierze się z tąd, że programy ERP operują zwykle na zaokrąglonych wartościach do max 2 miejsc po przecinku. Przez co np dając 0,01 i 0,03% rabatu w ERP masz tą samą cenę. A dla presty będzie już widoczna różnica 1 grosza.

[PrestaShark]

Hej. No właśnie zaokrąglanie ceny nie stanowi problemu. W preście masz możliwość wyboru jej zaokrąglania

 

Tryb zaokrąglania: klasyczny, nadrzędny, podrzędny

(Możesz wybrać jak zaokrąglane są ceny i kwoty kalkulowane przez sklep. Nadrzędnie zawsze zaokrągla w górę, podrzędnie zawsze zaokrągla w dół, klasycznie zaokrągla w górę lub w dół zależnie od kwoty (np 15.944 zostanie zaokrąglone do 15.94 a 15.946 zaokrąglone do 15.95).

 

Problem jest gdzieś w liczeniu kosztów dostawy

[() Maciej ()]

Masz rację ale połowicznie. Owszem da się ustawić różne tryby zaokrąglania, ale przy 15k produktów jakie mam w preście duża część z nich ma końcówki cen ,99 zamiast ,00, albo w drugą stronę ,01 zamiast ,00. Nie ma tu znaczenia jak ustawię wartości i tak będzie to samo.. tam gdzie naprawi się z 0,99 na 00 to zepsuje się reszta. Aby problem nie występował presta musiałaby w 100% mieć te same funkcje co oprogramowanie ERP do wyliczania wartości.

 

 

Wracając do Twojego problemu. Sprawdzałeś jakie wartości masz podane podatku VAT oraz jaką kwotę masz wpisaną w kosztach transportu ? Próbuję u siebie na testowym sklepie doprowadzić do takiego wyliczania cen i szczerze mówiąc póki nie zmieniłem kwoty kosztu transportu nie dało rady osiągnąć tego o czym piszesz.

Sprawdź też jak wygląda wartość zamówienia jeśli użyjesz w ERP wartości netto, a jak będzie to wyglądać w wartościach brutto.

 

Pamiętam też, że presta ma coś takiego jak "opakowanie prezentu", czy coś w ten deseń. Może tam masz wprowadzoną wartość 50gr i stąd różnica.

[PrestaShark]

Takie coś jest

 

 

 

omg...

 

poszedłem dalej i patrzcie co znalazłem

 

wklepałem cenę przesyłki netto taką jak wartość produktów netto żeby zobaczyć przeliczenia podatków. no i dostawa liczona jest prawidłowo bo podatek powinien być 86zł...

 

gdzie to poprawić dla produktów???

Edited January 27, 2016 by PrestaShark (see edit history)

[PrestaShark]

Zgłosiłem oficjalnie tego buga

http://forge.prestashop.com/browse/PSCSX-7628

 

masakra totalna

[iarts]

Dzień dobry,

czy udało się Panu rozwiązać ten problem z zaokrąglaniem cen?

[hakeryk2]

@iarts może to Ci pomoże 

 

[iarts]

@hakeryk2 Bardzo dziękuję za wskazówkę - wprowadziłem opisane przez Ciebie zmiany, ale o ile w przypadku rabatu czy kosztu wysyłki precyzja pól się zwiekszyła tak w total_paid_tax_excl i total_apid nadal jest do dwóch miejsc po przecinku co jest dziwne. Sprawdziłem 2 razy, na sztywno mamy "6" w Cart.php oraz wyczyściłem class-cache z katalogu "cache"... 😕

[hakeryk2]

@iartsW temacie który podlinkowałem są 3 posty i ostatni mówi o total_paid_tax_excl, trzeba też zmienić zmienną  $compute_precision = _PS_PRICE_COMPUTE_PRECISION_; na  $compute_precision = 6; na początku skryptu getOrderTotal i ogólnie możesz korzystać z tej zmiennej zamiast klepać 6 ręcznie.

Edited March 1, 2019 by hakeryk2 (see edit history)

[iarts]

@hakeryk2 Dzięki za tip! Tego nie znalazłem w Twoim poście. Nie mogę jednak znaleźć w Cart.php definicji zmiennej $compute_precision, gdzie ją mogę ustawić?

 

 

----EDIT

Znalazłem definicję w takiej postaci: $compute_precision = $configuration->get('_PS_PRICE_COMPUTE_PRECISION_');

Rozumiem, że powinienem ją zamienić na $compute_precision = 6; ?

Edited March 1, 2019 by iarts (see edit history)

[hakeryk2]

@iarts ogólnie mówimy o preście 1.6 więc jeśli masz coś innego to może być problem ale u mnie wygląda to tak, że ta zmienna jest na początku funkcji getOrderTotal i później zamiast 6 możesz wstawić $compute_precision w tamte miejsca wskazane w poście.
 

* @param bool $withTaxes With or without taxes
* @param int $type Total type
* @param bool $use_cache Allow using cache of the method CartRule::getContextualValue
* @return float Order total
*/
public function getOrderTotal($with_taxes = true, $type = Cart::BOTH, $products = null, $id_carrier = null, $use_cache = true)
{
    // Dependencies
    $address_factory    = Adapter_ServiceLocator::get('Adapter_AddressFactory');
    $price_calculator    = Adapter_ServiceLocator::get('Adapter_ProductPriceCalculator');
    $configuration        = Adapter_ServiceLocator::get('Core_Business_ConfigurationInterface');

    $ps_tax_address_type = $configuration->get('PS_TAX_ADDRESS_TYPE');
    $ps_use_ecotax = $configuration->get('PS_USE_ECOTAX');
    $ps_round_type = $configuration->get('PS_ROUND_TYPE');
    $ps_ecotax_tax_rules_group_id = $configuration->get('PS_ECOTAX_TAX_RULES_GROUP_ID');
    $compute_precision = 6;

    if (!$this->id) {
        return 0;
    }

[iarts]

@hakeryk2 Bardzo dziękuję, przeprowadzę więcej testów. Ogólnie bardzo dziwna to sprawa. Znalazłem firmę, która sprzedaje gotowy patch na to: https://www.presta-addons.net/en/content/7-incorrect-tax-rounding-and-application-in-prestashop-161 

Jednak oni mają chyba inne podejście ponieważ zmieniają sposób wyliczenia ceny brutto:

switch ($ps_round_type) { 
                case Order::ROUND_TOTAL: 
                    $pp = $price * (int)$product['cart_quantity']; 
                    $products_total[$id_tax_rules_group.'_'.$id_address] += $with_taxes?$tax_calculator->addTaxes($pp):$pp; break; 
                
                case Order::ROUND_LINE: 
                    $product_price = $price * $product['cart_quantity']; $pp = Tools::ps_round($product_price, $compute_precision); 
                    $products_total[$id_tax_rules_group] += $with_taxes?$tax_calculator->addTaxes($pp):$pp; 
                    break; 
                
                case Order::ROUND_ITEM: 
                    default: $product_price = /*$with_taxes ? $tax_calculator->addTaxes($price) : */$price; 
                    $pp = Tools::ps_round($product_price, $compute_precision) * (int)$product['cart_quantity']; 
                    $products_total[$id_tax_rules_group] += $with_taxes?$tax_calculator->addTaxes($pp):$pp; 
                    break; 
            }

Autor tego moda opisał to z resztą tutaj, ale Support PS go raczej zlekceważył:

http://forge.prestashop.com/browse/PSCSX-8005?_ga=2.66259566.1761284633.1551359641-610244094.1419267496

Edited March 1, 2019 by iarts (see edit history)

[hakeryk2]

Tak, też to widziałem i dlatego postanowiłem, że nie ma bata, że za to zapłacę aż tyle   tym bardziej, że wiem iż Presta domyślnie korzysta z wartości netto i przelicza je na brutto więc jeśli coś wrzuca do bazy i źle to zaokrągla to jest to tylko i wyłącznie wina zaokrąglenia. Aha, bo już nie pamiętam, trochę tych zmian poszło - czy na końcu funkcji getOrderTotal masz  return Tools::ps_round((float)$order_total, $compute_precision);

? 

[iarts]

@hakeryk2 Tak, na końcu funkcji mam również return Tools::ps_round((float)$order_total, $compute_precision);

Niestety, nadal dla sumy końcowej (netto/brutto) do bazy leci wartość z 2 miejscami po przecinku:

 

[iarts]

@hakeryk2 Dzięki! Po zmianie w PaymentModule.php cena netto zyskała już pełną wartość. Jednak kwota brutto zostaje z dwoma miejscami - rozumiem, że kwota brutto już zostaje z zaokrągleniem do 2 miejsc po przecinku?

[hakeryk2]

Nie miałem jeszcze z tym problemu więc się nie przejmowałem  Ważne, że total_paid_tax_excl * tax_value zawsze da poprawne brutto bo presta zawsze startuje z pozycji kwota bez podatu * podatek. Nigdy na odwrót. Choć dziwi mnie, że trochę te wartości u Ciebie się rozjeżdżają - u mnie zawsze gdy podzięle total_paid_tax_incl/1.23 zawsze otrzymam dokładnie tą samą wartość co mam w tax_excl. 

Ale...
Wprowadziłem ogrom zmian i nie do końca już pamiętam czy uwzględniłem wszystkie w poradniku. Jeśli jakoś by Ci to kolidowało z czymś to postaram się prześledzić zmiany we wszystkich plikach jak wprowadziłem.

Edited March 1, 2019 by hakeryk2 (see edit history)

[iarts]

@hakeryk2 Dziękuję za pomoc! Tak, właśnie też bardzo mnie dziwi to ostateczne zaokrąglenie kwoty brutto i szczerze mówiąc rozłożyłem ręce. Ten wątek włoskiego kolegi był dla mnie jakimś kierunkiem w poszukiwaniu przyczyny (zmiana kolejności naliczania). 

Gdybyś miał możliwość sprawdzenia co zmieniłeś u siebie pod kątem tabeli "total_paid" byłbym wdzięczny. Generalnie to powinieneś ten tutorial zrobić oficjalnie, bo z tego co widzę mnóstwo osób ma ten problem i nigdzie nie było rozwiązania.