Zlecenie: Przeniesienie ilości z jednego podmiotu do 2 podmiotu

[Paweł S. 0]

Witam,

 

Zlecę rozwiązanie problemu

Mamy dwie firmy, ale tylko z jednej synchronizujemy stany do sklepów online. Chodzi o to żeby z  firmy A przesłać do pola własnego firmy B  np. co 5 min lub co zmianę stanu w firmie A. 

Oba podmioty są na tej samej instancji MsSQL, dwie różne baz danych.

 

[Aga Zgaga 90]

Cześć, podpinamy się

Również coś takiego potrzebujemy, kiedyś już poruszaliśmy ten temat, ale... jakoś tak umarło i chętnie wrócimy do tematu.

Również mamy 2 firmy, na jednym serwerze ta sama instancja, dwie bazy i potrzebujemy, żeby z dwóch Subiektów synchronizowały się stany magazynowe.

W naszym przypadku nie jest ważne jak to będzie się odbywać, ważne żeby działało.

[Radomił Ząbik 310]

Też jestem ciekawy, czy ktoś ma pomysł na to, bo dla mnie wydaje się jedynie tworzenie odpowiednich dokumentów PW i RW, ale pojawia się wtedy spory problem, z ilością dokumentów, oraz jakimiś rezerwacjami.

Wydaje mi się, że lepiej by było przyjąć jeden podmiot jako główny, a ewentualnie oprogramować w sferze zdarzeniowej odpowiednie sprawdzanie stanu w głównej bazie, i przesłanie komendy, do tworzenia wydań z niej i ewentualnych przyjęć w bazie docelowej, ale to generalnie też dużo do rozważania i projektowania.

[Daniel Kozłowski 1 171]

42 minuty temu, Radomił Ząbik napisał:

Też jestem ciekawy, czy ktoś ma pomysł na to,...

Tego typu rozwiązania od lat oferujemy dla GT, funkcjonują pod nazwą "multistany", przy czym głównie do prezentowania stanów magazynowych z innych magazynów na listach towarów i pozycjach dokumentów (stany są kopiowane do pól towaru, jak pola własne czy opis, skopiowanie ich do innego podmiotu to już kosmetyka), co w nexo jest w standardzie, więc analogiczne rozwiązanie nie powstało jeszcze dla nexo, nawet nie mieliśmy / nie przypominam sobie zapytania. Technicznie jest to realizowane w sposób, którego Pan nie lubi czyli na poziomie bazy danych, można rozważyć częściowe wykorzystanie Sfery (wychwycenie zmian na bazie danych, okresowa sferyczna aktualizacja).

[Radomił Ząbik 310]

3 minuty temu, Daniel Kozłowski napisał:

Tego typu rozwiązania od lat oferujemy dla GT, funkcjonują pod nazwą "multistany", przy czym głównie do prezentowania stanów magazynowych z innych magazynów na listach towarów i pozycjach dokumentów (stany są kopiowane do pól towaru, jak pola własne czy opis, skopiowanie ich do

Ok, czyli tylko pokazywanie stanu z innego magazynu w polu własnym - czysto informacyjne, ok to luzik. Ja się zastanawiałem, czy ktoś wytworzył takie rozwiązanie, że w obu podmiotach stan jest trzymany faktycznie, tak, że można z niego korzystać w dokumentach, wydawać, rezerwować itp. co wydaje mi się technicznie, masakrą w utrzymaniu.

6 minut temu, Daniel Kozłowski napisał:

Technicznie jest to realizowane w sposób, którego Pan nie lubi czyli na poziomie bazy danych, można rozważyć częściowe wykorzystanie Sfery (wychwycenie zmian na bazie danych, okresowa sferyczna aktualizacja).

Tak, nie lubię, ale umówmy się, że pola własne jako końcówka bez praktycznie żadnych powiązań, to jest coś, co można czasem użyć, taki wyjątek w regule Biorąc to pod uwagę, i trzymanie stanu w polach własnych, to dobre zapytanie SQL, operujące na dwóch bazach, może to załatwić

[Daniel Kozłowski 1 171]

1 minutę temu, Radomił Ząbik napisał:

Ja się zastanawiałem, czy ktoś wytworzył takie rozwiązanie, że w obu podmiotach stan jest trzymany faktycznie, tak, że można z niego korzystać w dokumentach, wydawać, rezerwować itp. co wydaje mi się technicznie, masakrą w utrzymaniu.

Przede wszystkim nie widzę takiej potrzeby / nie miałoby to sensu - towar musi zostać formalnie sprzedany i zakupiony.

 

3 minuty temu, Radomił Ząbik napisał:

Tak, nie lubię, ale umówmy się, że pola własne jako końcówka bez praktycznie żadnych powiązań, to jest coś, co można czasem użyć, taki wyjątek w regule Biorąc to pod uwagę, i trzymanie stanu w polach własnych, to dobre zapytanie SQL, operujące na dwóch bazach, może to załatwić

Pola własne to był tylko przykład, równie dobrze można aktualizować "magazyn".

[Radomił Ząbik 310]

2 minuty temu, Daniel Kozłowski napisał:

Przede wszystkim nie widzę takiej potrzeby / nie miałoby to sensu - towar musi zostać formalnie sprzedany i zakupiony.

Jasne, też bym się w to nie chciał bawić. No w takiej formie, pozostaje jedynie zautomatyzowanie transferowania wydań/przyjęć między podmiotami i ich późniejsze fakturowanie, co już nie jest aż tak problematyczne, kwestia ustalenia zasady, jak gdzie i kiedy.

6 minut temu, Daniel Kozłowski napisał:

Pola własne to był tylko przykład, równie dobrze można aktualizować "magazyn".

Że na przykład update tablicy StanyMagazynowe? W sumie, jeśli na danym magazynie nie ma operacji, to się ona nie rozjedzie. No ale Ma Pan lata doświadczenia i wie, gdzie można zaszaleć

[Aga Zgaga 90]

7 minut temu, Daniel Kozłowski napisał:

Przede wszystkim nie widzę takiej potrzeby / nie miałoby to sensu - towar musi zostać formalnie sprzedany i zakupiony.

Jak widać w tym temacie, potrzeba taka jest

Tak nam wpadło do głowy, że mogą tworzyć się przyjęcia i rozchody z wybraną kategorią/cechą.

Wprowadzamy towar "A" na stan firmy "X".

Wtedy mamy towar "A" w firmie "X" - widoczny również na stanie w firmie "Y", bo utworzyło się PZ.

Sprzedajemy towar "A" w firmie "X" - wtedy w firmie "Y" tworzy się WZ.

 

Natomiast jeżeli sprzedamy towar "A" w firmie "Y" - to w firmie "X" tworzy się WZ z wybraną kategorią/cechą "firmaA".

Na koniec miesiąca firma "X" filtruje sobie WZ z kategorią/cechą "firmaA" i zbiorczo wystawia fakturę.

 

Analogicznie, jeżeli wprowadzamy towar na stan drugiej firmy.

 

Wystawianie WZ i PZ powinno odbywać się niezauważalnie, w tle, z możliwością ustawienia czasu synchronizacji od 1 minuty

 

 

[Radomił Ząbik 310]

5 minut temu, Aga Zgaga napisał:

Jak widać w tym temacie, potrzeba taka jest

W sensie potrzeba trzymania stanu w magazynie, zarówno w firmie X oraz Y, a nie jako pole własne w firmie Y? Tutaj jest ogromny problem logiczny, bo ten stan tam musi się jakoś pojawić. Łatwo to zrobić przez PW, ale jak Pan coś sprzeda w Y, to stan się odpowiednio pomniejszy, a chce Pan od razu z automatu zrobić WZ w X, oraz PZ w Y, gdzie po pierwsze PZ w Y, przywróci ponownie stan, a WZ w X, zniweluje stan i wymusi zmianę stanu w PW dla Y. W efekcie pewnie zablokują się totalnie stany, bo nie pokryją się wydania.

Dlatego zacząłem dopiskę do wątku, z ciekawością, czy ktoś wpadł na takie szalone perturbacje i jest w stanie utrzymać to w składzie i ładzie

 

Reszta co Pan pisze, jest jak najbardziej normalne. Można i co minutę. Można pokombinować z aplikacjami nasłuchującymi plus sfera zdarzeniowa i odpowiednio wystawiać wzajemnie WZ i PZ. Ale same stany, zgodnie z tym Co Pan Daniel pisze, a pewnie u nie jednego klienta to wdrażał, to pola własne w firmie Y wydają się najrozsądniejsze. Można się pokusić w firmie Y, o wystawianie ZK bez rezerwacji stanu, co wywoła ciąg WZ/PZ i po jego wykonaniu, zmieni status ZK i nic nie powinno się pogubić.

[Daniel Kozłowski 1 171]

8 minut temu, Aga Zgaga napisał:

32 minuty temu, Daniel Kozłowski napisał:

Przede wszystkim nie widzę takiej potrzeby / nie miałoby to sensu - towar musi zostać formalnie sprzedany i zakupiony.

Jak widać w tym temacie, potrzeba taka jest

Tak nam wpadło do głowy, że mogą tworzyć się przyjęcia i rozchody z wybraną kategorią/cechą.

Pisze Pani o zupełnie innej potrzebie niż poruszana w tym wątku - automatyzacji wymiany dokumentów między podmiotami, ja odnosiłem się do podglądu stanów magazynowych w innym podmiocie, gdzie dane do podglądu stanów magazynowych nie będą wykorzystywane na żadnych dokumentach. 

[Aga Zgaga 90]

 

 

3 minuty temu, Daniel Kozłowski napisał:

Pisze Pani o zupełnie innej potrzebie niż poruszana w tym wątku - automatyzacji wymiany dokumentów między podmiotami

Wydaje nam się, że napisaliśmy o tym, co w temacie "Zlecenie: Przeniesienie ilości z jednego podmiotu do 2 podmiotu"

Poniżej dokładne info o synchronizacji stanów... co prawda jest napisane o polach własnych, że "z  firmy A przesłać do pola własnego firmy B", ale wątek w dalszym ciągu ten sam

16 godzin temu, Paweł Socha napisał:

Mamy dwie firmy, ale tylko z jednej synchronizujemy stany do sklepów online. Chodzi o to żeby z  firmy A przesłać do pola własnego firmy B  np. co 5 min lub co zmianę stanu w firmie A.

 

12 minut temu, Radomił Ząbik napisał:

W sensie potrzeba trzymania stanu w magazynie, zarówno w firmie X oraz Y, a nie jako pole własne w firmie Y? Tutaj jest ogromny problem logiczny, bo ten stan tam musi się jakoś pojawić. Łatwo to zrobić przez PW, ale jak Pan coś sprzeda w Y, to stan się odpowiednio pomniejszy, a chce Pan od razu z automatu zrobić WZ w X, oraz PZ w Y, gdzie po pierwsze PZ w Y, przywróci ponownie stan, a WZ w X, zniweluje stan i wymusi zmianę stanu w PW dla Y. W efekcie pewnie zablokują się totalnie stany, bo nie pokryją się wydania.

Dlatego zacząłem dopiskę do wątku, z ciekawością, czy ktoś wpadł na takie szalone perturbacje i jest w stanie utrzymać to w składzie i ładzie

Nie jesteśmy fachowcami dlatego również poszukujemy podobnego rozwiązania.
Nie wiemy dokładnie jak to logiczne rozwiązać, jakie są możliwości w tym temacie

Staramy się podpowiedzieć, może ktoś coś z tego wyciągnie jakieś informacje i na tej podstawie coś uda się zrealizować, z czego chętnie byśmy skorzystali

Może jest, do zastosowania, jakaś blokada, żeby po wystawieniu dokumentu końcowego w jednej firmie i WZ w drugiej, nie zapętlało się kolejne wystawianie WZ. Tego niestety nie wiemy...

 

Dla nas nie ważne jest jak taki synchronizator miałoby funkcjonować, ważne, żeby działał

[Daniel Kozłowski 1 171]

6 minut temu, Aga Zgaga napisał:

Wydaje nam się, że napisaliśmy o tym, co w temacie "Zlecenie: Przeniesienie ilości z jednego podmiotu do 2 podmiotu"

Poniżej dokładne info o synchronizacji stanów... co prawda jest napisane o polach własnych, że "z  firmy A przesłać do pola własnego firmy B", ale wątek w dalszym ciągu ten sam

Dobrze, to moje niezrozumienie, gdyż odniosła się Pani do fragmentu wypowiedzi o innym / kolejnym procesie (transakcji między firmami), a ja w ogóle nie pomyślałem / nie dopuszczam synchronizacji przyrostowej dokumentami magazynowymi odzwierciedlanymi w drugim podmiocie (tak teraz rozumiem pomysł), gdzie poza dokumentami PZ/WZ, są przesunięcia, dokumenty wewnętrzne, korekty, poza ich dodawaniem mogą być edytowane, usuwane, a samo gromadzenia takich dokumentów będzie zabierało zasoby bazy danych i obniżało wydajność programu.

 

14 minut temu, Aga Zgaga napisał:

Dla nas nie ważne jest jak taki synchronizator miałoby funkcjonować, ważne, żeby działał

Rozumiem.

 

[Aga Zgaga 90]

Dobrze

 

Już wiem, to w naszym przypadku musi wyglądać tak:

Wprowadzamy towar "A" na stan firmy "X".

Wtedy mamy towar "A" w firmie "X" - widoczny również na stanie w firmie "Y", bo utworzyło się PZ, na podstawie FZ drugiej firmy.

Sprzedajemy towar "A" w firmie "X", tu wystawia się ZK - wtedy w firmie "Y" tworzy się WZ, ale nie tworzy się ZK.

 

Natomiast jeżeli sprzedamy towar "A" w firmie "Y", tu wystawia się ZK - to w firmie "X" tworzy się WZ z wybraną kategorią/cechą "firmaA".

Na koniec miesiąca firma "X" filtruje sobie WZ z kategorią/cechą "firmaA" i zbiorczo wystawia fakturę.

 

Pytanie, czy jest możliwe, żeby taki synchronizator wiedział, żeby brać pod uwagę wystawianie ZK i na drugiej firmie wystawiał WZ?

 

Wtedy nie powinno być zapętlania się wystawianie WZ/PZ

 

Czy dobrze myślimy? Co WY na to?

Edytowane 2 Grudnia 2022 przez Aga Zgaga