InsERT GT => Subiekt GT => Wątek zaczęty przez: micha w Sierpień 13, 2018, 10:53:08
-
W sobotę "coś" się stało przy zapisywaniu paragonu. Oczywiście pracownik nie ma pojęcia "co". W każdym razie efekt jaki dziś zastałem był taki:
- paragon miał niewywołany skutek (na 29szt towaru)
- lista towarów podawała stan 0.
- informator na zakładce ruch towaru podawał stan końcowy 29szt
- ostatnią pozycją w ruchu towaru wg informatora było wydanie 29szt z tego paragonu (który rzekomo nie wywoływał skutku!) i w kolumnie "narastająco" była wartość 0.
Próby wywołania skutku się nie powiodły, więc skasowałem trefny paragon. Efekt:
- lista towarów nadal podaje stan 0.
- informator na zakładce ruch towaru nadal podaje stan końcowy 29szt
- ostatnią pozycja w ruchu towaru w kolumnie "narastająco" podaje wartość 29.
Dodałem ponownie ten paragon, ale oczywiście skutku nie da się wywołać.
Odtworzyłem indeksy - nie pomogło.
Rozwalona baza danych? Jak naprawić? :-)
-
A co pokazują zakładki stany i stany w magazynach w informatorze dla tego towaru?
-
A co pokazują zakładki stany i stany w magazynach w informatorze dla tego towaru?
Rano było:
Stany: 0
Stany w magazynach: 0
Po skasowaniu trefnego paragonu jest:
Stany: ilość z dostawy 200, pozostało 29
Stany w magazynach: 0
-
Bez zajrzenia do bazy raczej się nie obejdzie. Fizycznie na magazynie masz 29 sztuk tego towaru?
-
Bez zajrzenia do bazy raczej się nie obejdzie.
Kurde, a gdzie zacząć szukanie...?
Fizycznie na magazynie masz 29 sztuk tego towaru?
Tak. (Tzn. teraz już nie, bo towar został sprzedany na ten trefny paragon... ale było 29. Nawet sprawdziłem na zapisach kamer, czy klient rzeczywiste dostał to, co miał dostać.)
-
Na oko wygląda, że Ci się "tylko" rozjechał stan w tabeli tw_Stan. Poprawienie tego w bazie jest banalne i mogę Ci nawet podesłać jak to ogarnąć jak mi podasz dodatkowe info ale robisz to na własną odpowiedzialność i dobrze by było żeby serwisant Ci potem zajrzał do bazy czy nie masz więcej takich niespodzianek.
-
Na oko wygląda, że Ci się "tylko" rozjechał stan w tabeli tw_Stan. Poprawienie tego w bazie jest banalne i mogę Ci nawet podesłać jak to ogarnąć jak mi podasz dodatkowe info ale robisz to na własną odpowiedzialność i dobrze by było żeby serwisant Ci potem zajrzał do bazy czy nie masz więcej takich niespodzianek.
Z ręczną poprawą wartości w tabeli to sobie poradzę... Zresztą i tak bawię się kopią.
Raczej chodzi mi o zrozumienie skąd problem. (Upał, deszcz meteorów i wybuchy na Słońcu?)
Kopia bazy "po sobocie" zawiera zapis w tabeli dok_MagRuch (-29szt), chociaż paragon nie ma przecież skutku. Chyba nie powinno nic być w tej tabeli, skoro nie ma skutku? Po usunięciu paragonu zapis ten zniknął. Czyli wygląda, jakby "skutek zaczął się wywoływać", ale z jakiegoś powodu nie doszedł do końca, a mimo to nie cofnęła się transakcja...
Takie rzeczy nie powinny się dziać... czy to jest znany problem w jakichś specyficznych okolicznościach?
-
Kopia bazy "po sobocie" zawiera zapis w tabeli dok_MagRuch (-29szt), chociaż paragon nie ma przecież skutku. Chyba nie powinno nic być w tej tabeli, skoro nie ma skutku? Po usunięciu paragonu zapis ten zniknął. Czyli wygląda, jakby "skutek zaczął się wywoływać", ale z jakiegoś powodu nie doszedł do końca, a mimo to nie cofnęła się transakcja...
No nie, nie powinno nic być w dok_magruch jak nie był wywołany skutek magazynowy. Sprawdzałeś czy w dok_pozycja są pozycje do tego zapisu i czy jest dokument w dok__dokument do tych pozycji.
-
No nie, nie powinno nic być w dok_magruch jak nie był wywołany skutek magazynowy. Sprawdzałeś czy w dok_pozycja są pozycje do tego zapisu i czy jest dokument w dok__dokument do tych pozycji.
W dok__Dokument jest tylko paragon (nie ma wz).
W dok_Pozycja w polu ob_DokMagId jest null (a w polu od_DokHanId identyfikator paragonu.)
Czyli chyba tak dokładnie powinno być przy założeniu, że nie ma skutku.
Piszę cały czas o kopii bazy z soboty wieczorem, bo oczywiście po usunięciu paragonu - zapisy w tych tabelach znikły.
Jak mogę ręcznie wyliczyć "to co informator pokazuje jako stan końcowy"? Porównałbym sobie to z tabelą tw_stan i zobaczył czy nie ma więcej takich kwiatków...
-
Podesłałem Ci coś na PW.
-
Czy paragon był opłacany w formie: płatność kartą ?
Pytam, bo my w firmie mieliśmy 6 takich przypadków w ostatnich 30 dniach. Za każdym razem płatność "przechodziła" przez terminal. To była cecha wspólna.
-
Czy paragon był opłacany w formie: płatność kartą ?
Pytam, bo my w firmie mieliśmy 6 takich przypadków w ostatnich 30 dniach. Za każdym razem płatność "przechodziła" przez terminal. To była cecha wspólna.
Tak, kartą!
-
Takie rzeczy nie powinny się dziać... czy to jest znany problem w jakichś specyficznych okolicznościach?
[/quote]
U nas przyczyna jest taka, że kasjerka sprzedaje towar którego nie ma na stanie w SGT. W ustawieniach poszczególnych dokumentów, przy sprzedaży z formą płatności przez terminal jest odpowiedzialna za to opcja czy może sprzedać czy nie. A jeśli może to czy dokument ma zapisać się ze skutkiem magazynowym odłożonym czy wycofanym. Do tego momentu jest cacy i wszystko jasne.
Problem zaczyna się pojawiać, kiedy wprowadzimy brakujący towar na stan ( inwentaryzacją bądź prościej PW ) i chcemy wykonać stan na magazynie. Wtedy towar schodzi jakby "podwójnie" i rozjeżdżają się tabele.
Do tej pory ten mechanizm działał prawidłowo ale takie dziwy zauważyliśmy po ostatniej aktualizacji i wg mnie jest to jakiś bubel, który podlega zgłoszeniu do producenta. My z tego powodu naprawialiśmy bazę danych.
Żeby było śmieszniej u nas nie da się zablokować sprzedaży ponad stan przy płatności przechodzącej przez terminal, gdzie w poprzedniej wersji było to standardem.
-
Cholera! Odkryłem jeszcze dziwniejszy przypadek!
Paragon wystawiony z wywołanym skutkiem. Jednak okazało się, że po operacji Subiekt podaje stan niezgodny z rzeczywistością. Odkryłem, że Auto-WZ do tego paragonu zdejmuje ze stanu ten sam towar 2x. Po prostu w dwóch kolejnych wierszach było 2 razy to samo. Wycofałem skutek i wywołałem ponownie - efekt: Na nowo wygenerowanym AutoWZ pozycja jest już zdjęta tylko raz (i dobrze!), ale za to rozjechał się stan towaru na zakładkach "stany" i "stany w magazynach".
No i oczywiście paragon był płatny kartą... Szlag mnie trafi!
-
Skoro coś się skopało to mogło się skopać na więcej niż 1 towarze (np na wszystkich, które były na jakimś feralnym dokumencie).
A jak już się posypało to konsekwencje mogą się ciągnąć jak smród po gaciach.
-
Jeśli dobrze rozumiem wcześniejsze posty to te niespodzianki zdarzają się tylko przy dokumentach z płatnością kartą przekazywaną na terminal?
-
Jeśli dobrze rozumiem wcześniejsze posty to te niespodzianki zdarzają się tylko przy dokumentach z płatnością kartą przekazywaną na terminal?
Tak. Właśnie wywaliłem integrację z terminalem w cholerę. Wolę terminal w trybie ręcznym niż takie kwiatki.
A w przyszłym tygodniu będę analizował bazę pod kątem kolejnych przeoczonych kwiatków... Jest co sprawdzać, bo paragonów kartowych trochę było...
-
Cholera! Odkryłem jeszcze dziwniejszy przypadek!
Paragon wystawiony z wywołanym skutkiem. Jednak okazało się, że po operacji Subiekt podaje stan niezgodny z rzeczywistością. Odkryłem, że Auto-WZ do tego paragonu zdejmuje ze stanu ten sam towar 2x. Po prostu w dwóch kolejnych wierszach było 2 razy to samo. Wycofałem skutek i wywołałem ponownie - efekt: Na nowo wygenerowanym AutoWZ pozycja jest już zdjęta tylko raz (i dobrze!), ale za to rozjechał się stan towaru na zakładkach "stany" i "stany w magazynach".
No i oczywiście paragon był płatny kartą... Szlag mnie trafi!
dokładnie ta sama sytuacja.
-
Wyniki analizy:
- Tabela dok__Dokument zawierała ten paragon 1 raz oraz AutoWZ - także 1 raz.
- Paragon miał 3 pozycje, więc tabela dok_Pozycja zawierała 3 odpowiednie wiersze, ładnie powiązane z paragonem (ob_DokHanId) oraz wz-ką (ob_DokMagId). Tu nie było żadnego nadmiaru.
Jednakże WZ-ka wyświetlona w Subiekcie pokazywała 5 wierszy - z czego pierwszy 2x, drugi 2x, trzeci 1x. Przyczyna leżała w tabeli dok_MagRuch, gdzie z niewiadomych przyczyn pojawiły się zduplikowane wpisy dla dwóch pierwszych towarów - przykład w załączeniu.
Wycofanie skutku z paragonu i ponowne go wywołanie spowodowało usunięcie zwielokrotnionych wpisów z dok_MagRuch. Ale efektem ubocznym było popsucie stanu magazynowego. W tej chwili mam takie dane w informatorze:
1) na zakładce ruch towaru widzę 31szt
2) na zakładce stany widzę jedną dostawę - pozostało 30 szt
3) na zakładce stany w magazynach widzę 30 szt
Na prawdę mam w magazynie 31 szt.
Błąd (3) mogę w zasadzie ręcznie poprawić w bazie w tw_Stan, ale to mi nie poprawi błędu (2)... Co z tym zrobić?
Na szczęście analiza bazy wykazała, że (chyba...) nie ma więcej niezgodności w dok_MagRuch...
-
Pytanie do ekspertów - czy poprawka w polu mr_Pozostalo z 30 na 31 wystarczy do rozwiązania problemu?
(patrz załącznik - jak widać wydania sumują się do 19, a nie do 20).
-
Insert przyznał, że jest to błąd w programie, który będzie naprawiony w jednej z najbliższych wersji.
Na razie trzeba unikać scenariusza ze sprzedażą towaru, którego nie ma nastanie połączonego z płatnością via terminal.
-
Zdaje się, że właśnie pojawiła się ta poprawka:
https://www.insert.com.pl/dla_uzytkownikow/subiekt_gt/ulepszenia/opis_zmian_sp.html
-
Fajnie ,że poprawka się pojawiła ale co z niezgodnymi stanami które spowodował program ? jest jakieś narzędzie do skorygowania tych stanów ? bo nie wyobrażam sobie grzebania w bazie.
falcon32
-
Insert napisał, zeby wysłać bazę do nich i będzie potraktowana ekspresowo.