[Sfera] Wykrywanie zmiany stanu magazynowego

[Łukasz Gorzelańczyk 0]

Witam,

poszukuje sposobu "wyciągnięcia" przez Sferę i synchronizacji stanów magazynowych asortymentu, które uległy zmianie od określonej daty. StanMagazynowy nie posiada nagłówka, z którego mógłbym wyciągnąć datę modyfikacji. Zmiana stanu magazynowego nie aktualizuje tez nagłówka w asortymencie. 

 

Jedynym pomysłem jaki mam jest wykrywanie nowych dokumentów i wyciąganie z nich asortymentów. Czy miał już ktoś może podobny problem? Mógłby ktoś podpowiedzieć jak najprościej wyciągnąć te dokumenty?

 

pozdrawiam

 

[Radomił Ząbik 308]

Tabela Przychody z bazy danych zapewne Pana interesuje. Tylko z tymi zmianami od określonej daty, to zależy jak chciałby być Pan dokładny, to jest tam kolumna Data. Jeśli jednak interesowały by Pana dokładnie modyfikacje, to trzeba by się oprzeć o Timestamp - może być tak, że ktoś się pomyli na dokumencie przyjęcia i po paru dniach go poprawi, Data się nie zmieni, ale Timestamp tak.

 

Nie wiem, jaki jest Pana dokładny cel, bo może zasugerowałbym coś innego

[Łukasz Czarnowski 17]

6 godzin temu, Łukasz Gorzelańczyk napisał:

poszukuje sposobu "wyciągnięcia" przez Sferę i synchronizacji stanów magazynowych asortymentu, które uległy zmianie od określonej daty

Jestem również ciekaw, czy jest na to sprytna metoda, ale czy nie wystarczy cykliczny odczyt całości stanów i weryfikacja różnic z poprzednim odczytem na lokalnym (cache) lub zdalnym zasobie?

[Łukasz Gorzelańczyk 0]

W dniu 10.03.2022 o 16:06, Łukasz Czarnowski napisał:

Jestem również ciekaw, czy jest na to sprytna metoda, ale czy nie wystarczy cykliczny odczyt całości stanów i weryfikacja różnic z poprzednim odczytem na lokalnym (cache) lub zdalnym zasobie?

Niestety mowa tutaj o około 40000 towarów. Ze względu na potrzebę utrzymania jak największej dokładności, koniecznym jest odświeżanie co minutę.

W dniu 10.03.2022 o 11:11, Radomił Ząbik napisał:

Tabela Przychody z bazy danych zapewne Pana interesuje. Tylko z tymi zmianami od określonej daty, to zależy jak chciałby być Pan dokładny, to jest tam kolumna Data. Jeśli jednak interesowały by Pana dokładnie modyfikacje, to trzeba by się oprzeć o Timestamp - może być tak, że ktoś się pomyli na dokumencie przyjęcia i po paru dniach go poprawi, Data się nie zmieni, ale Timestamp tak.

 

Nie wiem, jaki jest Pana dokładny cel, bo może zasugerowałbym coś innego

Dokładnym celem jest wykrycie, dla których towarów zmienił się stan magazynowy i "odświeżenie" ich w zewnętrznym systemie. Interesowałyby mnie tabele Przychody oraz Rozchody. Chyba, że istnieje inne miejsce, w którym można znaleźć takie informacje?

Na chwile obecną mam 2 pomysły:

 

1. Za pomocą SQL połączyć dane o dacie oraz id asortymentu z tych 2 tabel i wyciągnąć sobie towary które musze odświeżyć. Problemem tutaj jest wykrywanie rzeczy, które się faktycznie zmieniły od ostatniego odświeżenia. W przypadku jednej tabeli zapisywałbym datę oraz id ostatniego wpisu, który przetworzyłem i przy kolejnym sprawdzeniu zaczynał od tego miejsca. W przypadku dwóch miejsc musiałbym pamiętać osobno dla obydwu tabel.

2. Utworzyć osobną tabelę, z kolumnami ID asortymentu oraz datą modyfikacji, a na tabelę Przychody i Rozchody nałożyć triggery, które będą tworzyć/aktualizować wpisy w mojej tabeli. 

[Radomił Ząbik 308]

2 godziny temu, Łukasz Gorzelańczyk napisał:

Dokładnym celem jest wykrycie, dla których towarów zmienił się stan magazynowy i "odświeżenie" ich w zewnętrznym systemie. Interesowałyby mnie tabele Przychody oraz Rozchody. Chyba, że istnieje inne miejsce, w którym można znaleźć takie informacje?

Te tabele są potrzebne do określenia dokładnych przychodów i rozchodów partii. Jeśli nie działa Pan na partiach, to wystarczy tabela StanyMagazynowe - będzie zdecydowanie wydajniej

 

Co do realizacji Pana problemu, to pytanie, czy kluczowe jest dla Pana ta zmiana i jej rejestrowanie, czy chodzi tutaj raczej, o nie odświeżanie wszystkiego co się zmieniło. Robiłem takie porównania nie raz i wszystko zależy od tego co chce się uzyskać. Ale na moje można to zrobić tak:

- do tablicy w systemie, do którego mają trafiać stany, dodajemy kolumnę modyfikacja, którą uzupełniamy rzutowanym na INT polem Timestamp z StanyMagazynowe

- podczas cyklicznego uruchamiania skryptu, odczytujemy MAX kolumny modyfikacja, z systemu, do którego eksportujemy i z tablicy StanyMagazynowe, pobieramy wiersze z bazy NEXO, których Timestamp, jest większe niż to MAX z bazy do której eksportujemy

 

Dodatkowo dochodzą kwestie optymalizacyjne. Nie wiem, z jakiej bazy Pan korzysta, ale dla SQL, dobrze jest aby w drugiej bazie ID asortymentu było analogiczne i było kluczem głównym, wtedy można zastosować INSERT ON DUPLICATE KEY UPDATE i taką aktualizacje stanu, nawet dla kilku tysięcy pozycji, wrzucić jednym zapytaniem, lub pakietowo w zależności od ograniczeń serwera bazy danych.

[Krzysztof Bojakowski 12]

Witam.

 

Też ostatnio w podobnym czasie poruszałem ten temat w innym dziale oraz temacie. 

 

Dzięki podpowiedzią innych dowiedziałem się o triggerach, które tak prawdę mówiąc wydaje mi się, ze rozwiązują cały problem czasu ( dopiero się nauczyłem  ). Trigger sam aktualizuje pośrednią tabelę prze lub po insert, update czy też delete. 

 

Ciągle się uczę SQL-a.

 

W triggerze zamiennie za "insert on dubicate key ...". użyłem MERGE. Dla mnie łatwiejsze zwłaszcza przy łączeniu kilku tabel. 

 

Mam jednak problem z aktualizacją MySQL bezpośrednio z triggera. do łączenia się z bazą MySQL u używam opcji LikedServer poprzez ODBC. Jeśli uruchamiam update z SSMS lum sqlcmd to mysql aktualizuje się bez problemu. Problem jest gdy kod wrzucam do triggera - wtedy wywala się subiekt..

 

 

żeby nie powielać wpisu. może ktoś z Was spotkał się z takim problemem 

https://forum.insert.com.pl/index.php?/topic/74745-aktualizacja-stanu-magazynowego-sql/

 

[Krzysztof Bojakowski 12]

Przeglądając jeszcze dokumentację INSERT-u napotkałem się na tabele VENDERO jak i trigery VENDERO w tabeli stany magazynowe. Trigery są wyłączone.

 

Może tutaj znajdzie się jakieś rozwiązanie.

 

TRIGGER [ModelDanychContainer].[Vendero_StanyMagazynoweSynch_Update]

TRIGGER [ModelDanychContainer].[Vendero_StanyMagazynoweSynch_Insert]

TRIGGER [ModelDanychContainer].[Vendero_StanyMagazynoweSynch_Delete]

 

Ja na dzień dzisiejszy co 10 min robię select na tabelach Asortymentu oraz stany_magazynowe =(stany_magazynu - (reserwacja+rezerwacja+rezerwacja) ) i porównuję to z własną tabelą. W sytuacji gdy stan jest różny to zmieniam wartość Do_aktualizacji z 0 na 1 i kolejnymi zapytaniami wysyłam do myslql na hosting.

 

Nie wiem na ile takie rozwiązanie będzie/jest wydajne. Na dzień dzisiejszy przenoszę dane z innego programu i pozycji mam 100 - docelowo będzie ok 15 do 20tys. i dzienne ok 2-4 tys. zmian stanu w bazie.

 

Jednakże zastanawiam się nad użyciem trigera, który znacząco ułatwił by sprawę. 

 

W kwestii bezpieczeństwa i używaniem trigera to, korzystam z 2 programów od 2 różnych firm, jedna z nich jest na liście insert i używa trigerów w tabelach insertu ale dane wysyła do bazy stworzonej przez siebie co mi się podoba  bo tabele nie mieszają się z insertem. Program aktualizowany raz  na 1-2 lata i nic się nie wysypało do tej pory po żadnej z aktualizacji subiekta. Z kolei drugiej firmy nie ma na liście insert i tabele dodała do bazy insertu, ale nie używa trigerów. Obydwa programy działają podobnie ale funkcjonalnością uzupełniają się. Program z trigerami działa szybciej. 

 

Pozdrawiam