Samoczynne powiększanie stanów magazynowych

[droyy]

Cześć, mój pierwszy post i chyba pierwszy problem, który, aż tak dał nam popalić.

 

Niedługo po uruchomieniu nowego sklepu, zaobserwowaliśmy że niektóre produkty same zwiększają swój fizyczny stan magazynowy (zaawansowane zarządzanie magazynem). Np produkt był dodany wieczorem w ilości sztuk 10. Rano było już go 50 na stanie. Czasami realny stan również ulega samoczynnej zmianie ale nie zawsze.

W zakładce "Ruch magazynowy" nie widać tych zmian.

 

Nie dotyka to wszystkich produktów, ale pomiędzy nimi nie ma żadnego powiązania. (Były dodawane w innym czasie, dodane są do innej kategori itp itd). Nie ma żadnych punktów wspólnych dla produktów których stan magazynowych szaleje.

 

Wczoraj obserwując jeden produkt, zauważyłem że jego fizyczny stan magazynowy, zwiększał się równo co godzinę o 1 sztukę.

 

24 godziny temu wykonałem dokładną kopię strony oraz bazy 1:1 i umieściłem ją na tym samym serwerze (ta sama wersja php. apache, mysql itp). Na kopii strony od wczoraj, żaden produkt nie zwiększył swojego stanu czyli wszystko jest okej. W tym samym czasie, na wersji produkcyjnych, było takich produktów kilkanaście. Oczywistym jest dla mnie, że problem ten związany jest z ruchem i działaniem użytkowników na stronie ale jak to możliwe?

W międzyczasie przenosiliśmy stronę z hostingu współdzielonego na server vps. W obu przypadkach ten sam problem.

 

Brakuję nam pomysłu, co jeszcze możemy zrobić aby wychwycić problem i go rozwiązać?

 

Będziemy wdzięczni za każdą podpowiedź. Z góry dzięki.

 

Poniżej informacje konfiguracyjne.

 

Wersja PrestaShop 1.6.1.11

Informacja o serwerze Linux #1 SMP Thu Jun 29 13:01:59 MSK 2017 x86_64

Wersja oprogramowania serwera Apache/2

Wersja PHP 7.1.8

Limit pamięci 512M

Maksymalny czas wykonywania 1300

Wersja MySQL 5.6.36-log

Silnik MySQL InnoDB

Sterownik MySQL DbPDO

 

[endriu107]

Powinny być jakieś zapytania do bazy lub triggery które robią update na bazie musisz je wyłapać i prześledzić co je wywołuje, poza tym ta wersja presty chyba nie działa dobrze z tą wersja php z tego co pamiętam to maxymalnie z 7.0.6

[droyy]

Triggery sprawdzałem, jest pusto.

Początkowo sklep działał na wersji PHP 5.6 i było to samo.

Proszę zauważyć, że obecnie na tym samym serwerze mam identyczne kopie sklepu i na produkcyjnym są błędy a na testowym jest okej,

Jedyna różnica między nimi to to, że w tym pierwszym siedzą klienci i robią zakupy.

 

Sprawdzałem select SUBSTRING_INDEX(host,':',1) as 'ip' from information_schema.processlist oraz show triggers i jest czysto.

[hakeryk2]

Czy produkty które się dodają były zakupione czy stany magazynowe zmieniają również te, które nad którymi nie wykonano żadnej akcji?

[vekia]

sposobem na wyłapanie jest włączenie logowania zapytań mysql.

jeżeli masz dostęp do konsoli na hostingu

 

 

mysqld --log=nazwa_pliku

lub zmiana konfiguracji mysql'a

log = nazwa_pliku

wtedy czekamy na zapełnienie się logów i wychwycenie zapytania które aktualizuje stock. Na podstawie daty i konkretnej godziny zapytania sprawdzamy apache access log i mamy jak byk plik odpowiedzialny za ten update, a to już krok do rozwiązania problemu

[droyy]

Czy produkty które się dodają były zakupione czy stany magazynowe zmieniają również te, które nad którymi nie wykonano żadnej akcji?

 

Odkryłem, że produkty, które się same zwiększają, wcześniej były zakupione przez PayU i ich transakcje zostały niedokończone.

 

 

sposobem na wyłapanie jest włączenie logowania zapytań mysql.

jeżeli masz dostęp do konsoli na hostingu

lub zmiana konfiguracji mysql'a

log = nazwa_pliku

wtedy czekamy na zapełnienie się logów i wychwycenie zapytania które aktualizuje stock. Na podstawie daty i konkretnej godziny zapytania sprawdzamy apache access log i mamy jak byk plik odpowiedzialny za ten update, a to już krok do rozwiązania problemu

 

Dzięki, po zbadaniu logów okazało się, że updejty stanów wysyła moduł PayU.

Odnalazłem zamówienie ze statusem PayU pending, w którym to zamówieniu jest produkt który sam się zwiększa.

 

Screen odnośnie pending: https://scr.hu/lL6BV6

 

Jak widać, zamówienie jest z 22-08.

 

Zalogowałem się do PayU i odnalazłem to zamówienie. Okazuje się, że PayU co godzinę próbuje wysłać status ORDER_STATUS_CANCEL i odbija się od błędu.

Screen: https://scr.hu/3z8A30

 

Po wciśnięciu przycisku "ponów", PayU ponownie wysyła ten status do sklepu i stan fizyczny produktu ulega powiększeniu.

 

W tym samym czasie, error logi pokazują coś takiego:

 

[sun Sep 03 15:05:42.888691 2017] [fcgid:warn] [pid 31062:tid 140112480241408] [client 162.158.202.104:33752] mod_fcgid: stderr: PHP Notice: Trying to get property of non-object in /.../public_html/classes/stock/StockManager.php on line 92

[sun Sep 03 15:05:42.888717 2017] [fcgid:warn] [pid 31062:tid 140112480241408] [client 162.158.202.104:33752] mod_fcgid: stderr: PHP Notice: Trying to get property of non-object in /.../public_html/classes/stock/StockManager.php on line 92

[sun Sep 03 15:05:42.888723 2017] [fcgid:warn] [pid 31062:tid 140112480241408] [client 162.158.202.104:33752] mod_fcgid: stderr: PHP Notice: Trying to get property of non-object in /.../public_html/classes/stock/StockManager.php on line 93

[sun Sep 03 15:05:42.888729 2017] [fcgid:warn] [pid 31062:tid 140112480241408] [client 162.158.202.104:33752] mod_fcgid: stderr: PHP Notice: Trying to get property of non-object in /.../public_html/classes/stock/StockManager.php on line 93

[sun Sep 03 15:05:42.888734 2017] [fcgid:warn] [pid 31062:tid 140112480241408] [client 162.158.202.104:33752] mod_fcgid: stderr: PHP Notice: Trying to get property of non-object in /.../public_html/classes/stock/StockManager.php on line 94

[sun Sep 03 15:05:42.888740 2017] [fcgid:warn] [pid 31062:tid 140112480241408] [client 162.158.202.104:33752] mod_fcgid: stderr: PHP Notice: Trying to get property of non-object in /.../public_html/classes/stock/StockManager.php on line 94

 

Poniżej zawartość tych linijek w StockManager.php

'id_employee' => (int)$context->employee->id ? (int)$context->employee->id : $employee->id,
'employee_firstname' => $context->employee->firstname ? $context->employee->firstname : $employee->firstname,
'employee_lastname' => $context->employee->lastname ? $context->employee->lastname : $employee->lastname,

Jak to możliwe, że próba wysłania zaktualizowanego statusu z PayU powiększa stan magazynowy produktu, którego dotyczyło zamówienie?

 

Korzystam z oficjalnego modułu https://github.com/PayU/plugin_prestashop , wersja 3.0.2

[hakeryk2]

 

 

Jak to możliwe, że próba wysłania zaktualizowanego statusu z PayU powiększa stan magazynowy produktu, którego dotyczyło zamówienie?

 

Presta w momencie anulowania zamówienia zwraca na magazyn zakupione produkty z danego zamówienia. (Złożenie zamówienia -2szt produktu A, -5szt produktu B, Anulowanie zamówienia +2szt produkt A, +5szt produktu .

 

Przydatne, ale warto pamiętać, że może to powodować błędy takie jak Twoje lub gdy mamy w przypadek w którym, ktoś coś zamówił, my anulowaliśmy zamówienie, a następnie przywróciliśmy je zmieniając status na płatność zaakceptowana, a następnie znowu anulowaliśmy - wtedy na magazyn produkty wrócą nam 2x ponieważ po pierwszym anulowaniu gdy zmienia się status na np Oczekiwanie na płatność Presta już nie ściągnie z magazynu tych rzeczy i podwójne anulowanie zwiększy dwukrtonie ilość produktów na magazynie. 

 

Błąd możesz zgłosić twórcy wtyczki.

 

 

[droyy]

Presta w momencie anulowania zamówienia zwraca na magazyn zakupione produkty z danego zamówienia. (Złożenie zamówienia -2szt produktu A, -5szt produktu B, Anulowanie zamówienia +2szt produkt A, +5szt produktu .

 

Przydatne, ale warto pamiętać, że może to powodować błędy takie jak Twoje lub gdy mamy w przypadek w którym, ktoś coś zamówił, my anulowaliśmy zamówienie, a następnie przywróciliśmy je zmieniając status na płatność zaakceptowana, a następnie znowu anulowaliśmy - wtedy na magazyn produkty wrócą nam 2x ponieważ po pierwszym anulowaniu gdy zmienia się status na np Oczekiwanie na płatność Presta już nie ściągnie z magazynu tych rzeczy i podwójne anulowanie zwiększy dwukrtonie ilość produktów na magazynie. 

 

Błąd możesz zgłosić twórcy wtyczki.

 

 

 

Dzięki hakeryk2, wszystko jasne.

 

Skontaktuje się z supportem wtyczki.

 

A czy błąd/warn w logach mogę jakoś naprawić? Warn pojawia się w momencie wysłania statusu przez PayU do sklepu. Nie wiem czy to po stronie wtyczki wina czy sklepu?

 

[sun Sep 03 15:05:42.888691 2017] [fcgid:warn] [pid 31062:tid 140112480241408] [client 162.158.202.104:33752] mod_fcgid: stderr: PHP Notice: Trying to get property of non-object in /.../public_html/classes/stock/StockManager.php on line 92

[sun Sep 03 15:05:42.888717 2017] [fcgid:warn] [pid 31062:tid 140112480241408] [client 162.158.202.104:33752] mod_fcgid: stderr: PHP Notice: Trying to get property of non-object in /.../public_html/classes/stock/StockManager.php on line 92

[sun Sep 03 15:05:42.888723 2017] [fcgid:warn] [pid 31062:tid 140112480241408] [client 162.158.202.104:33752] mod_fcgid: stderr: PHP Notice: Trying to get property of non-object in /.../public_html/classes/stock/StockManager.php on line 93

[sun Sep 03 15:05:42.888729 2017] [fcgid:warn] [pid 31062:tid 140112480241408] [client 162.158.202.104:33752] mod_fcgid: stderr: PHP Notice: Trying to get property of non-object in /.../public_html/classes/stock/StockManager.php on line 93

[sun Sep 03 15:05:42.888734 2017] [fcgid:warn] [pid 31062:tid 140112480241408] [client 162.158.202.104:33752] mod_fcgid: stderr: PHP Notice: Trying to get property of non-object in /.../public_html/classes/stock/StockManager.php on line 94

[sun Sep 03 15:05:42.888740 2017] [fcgid:warn] [pid 31062:tid 140112480241408] [client 162.158.202.104:33752] mod_fcgid: stderr: PHP Notice: Trying to get property of non-object in /.../public_html/classes/stock/StockManager.php on line 94

[hakeryk2]

Wydaje mi się, że ten warning bierze się stąd, że próbuje utworzyć obiekt użytkownika, ale że go nie ma bo zadanie wykonuje automat (ale mogę się mylić) - ogólnie - błąd jest nieistotny dla działania.

 

Pamiętaj to warning, a nie error więc skrypt leci dalej.

 

U siebie wprowadziłem kilka zmian które tworzą historię zmian na magazynie (tzn każdy produkt ma historię co kto i kiedy, o ile sztuk i skąd oraz jaka akcja to wywołała) tylko przez to, że nie mogłem namierzyć czy to pracownik spitolił sprawę czy oprogramowanie. Problem w tym, że pisałem je ad hoc i kompletnie nie pamiętam już co gdzie edytowałem by to osiągnąć.

Edited September 3, 2017 by hakeryk2 (see edit history)

[droyy]

 

 

U siebie wprowadziłem kilka zmian które tworzą historię zmian na magazynie (tzn każdy produkt ma historię co kto i kiedy, o ile sztuk i skąd oraz jaka akcja to wywołała) tylko przez to, że nie mogłem namierzyć czy to pracownik spitolił sprawę czy oprogramowanie. Problem w tym, że pisałem je ad hoc i kompletnie nie pamiętam już co gdzie edytowałem by to osiągnąć.

 

hakeryk2, taki skrypt mógłby nam zaoszczędzić spooro problemów w przyszłości. Udałoby Ci się to odkopać? Chętnie odkupimy.

[ancona]

Quote

U siebie wprowadziłem kilka zmian które tworzą historię zmian na magazynie (tzn każdy produkt ma historię co kto i kiedy, o ile sztuk i skąd oraz jaka akcja to wywołała) tylko przez to, że nie mogłem namierzyć czy to pracownik spitolił sprawę czy oprogramowanie. Problem w tym, że pisałem je ad hoc i kompletnie nie pamiętam już co gdzie edytowałem by to osiągnąć

 

 

a taka akcja nie jest standardowa w "Wymiana zaopatrzenia" ?

[hakeryk2]

Nie korzystam z zaawansowanego zarządzania magazynem a to jest chyba tam.

[ancona]

hakeryk2 mamy właśnie u nas włączone zaawansowane zarządzanie magazynem i taki problem występuje tylko przy dwóch produktach. W ciągu jednego dnia stan zwiększył się z 70 tys na 160tys. ... Twórca wtyczki (do bitcoinów) twierdzi, że to nie wina modułu, ale szukamy rozwiązania.