Radomił Ząbik 308 Napisano 12 Sierpnia 2021 Udostępnij Napisano 12 Sierpnia 2021 w [Sfera] Adres dostawy na WZ, inny niż na ZK, od wersji 36 Po aktualizacji do wersji 36, zauważyliśmy, że podczas przetwarzania sferycznie ZK na WZ, zmienia nam się adres dostawy, na podstawowy w danych klienta. W informacjach o zmianach, nie doszukałem się nic w temacie. Wstawiam kod wykonujący poniżej. Mam podejrzenie, że za problem odpowiada jakieś dziwne obejście (strzelam, że jeszcze ustalone z Panem Jarkiem w 2016 roku), dotyczące Nabywcy. // przeniesienie parametrów z ZK ParametryGrupowaniaPodstawowe parametryGrupowania = new ParametryGrupowaniaPodstawowe(); parametryGrupowania.MetodaGrupowaniaPozycji = MetodaGrupowaniaPozycji.BezKonsolidacji; parametryGrupowania.MetodaWyliczeniaCen = MetodaWyliczeniaCen.PrzepisanieZDokumentuGlownego; parametryGrupowania.MiejsceDostawy = zk.MiejsceDostawy; parametryGrupowania.MiejsceDostawyTyp = MiejsceDostawyTyp.Nabywca; parametryGrupowania.NabywcaSprzedawca = zk.NabywcaSprzedawcaWybrany; IAplikatorSkutkowMagazynowych aplikatorSM = (IAplikatorSkutkowMagazynowych)wz; wz.Dane.Magazyn = mag; wz.Dane.StatusDokumentu = statusyDD.Rozchod_WydanyTowar; wz.Dane.Podtytul = zk.Podtytul; IDokumentZRozbiciem dok = (IDokumentZRozbiciem)wz; // wypełnienie pozycji na podstawie ZK foreach(var posadd in results.pos) { int posdocid = posadd.docid; int posid = posadd.id; decimal posq = posadd.quantity; int posbatch = posadd.batch; string comment = posadd.comment; var zamowienie = zamowienia.Dane.Wszystkie().Where(p => p.Id == posdocid).FirstOrDefault(); // znalezienie zamówienia var poz = wz.WypelnijNaPodstawieZK(zamowienie.Pozycje.Where(p => p.Id == posid),zamowienie,parametryGrupowania).Single(); // dodanie pozycji z ZK Console.WriteLine("Dodanie pozycji: "+posid+", "+poz.AsortymentAktualny.Nazwa); poz.Opis = comment; poz.CenaRecznieEdytowana = true; if(posadd.batch!=null) { poz.Ilosc = 0; // ustawiamy na 0, wyjdzie z rozbicia aplikatorSM.AplikujSkutkiMagazynowe(poz); // poprawka od Insertu na poprawne działanie skutku magazynu var r = dok.RozpocznijRozbicie(poz) as IRozbiciePozycjiRozchodowe; Console.WriteLine("Wprowadzenie partii: "+posbatch+" w ilości "+posq); r.Pozycje.Where(p => p.PartiaZrodlowa.Id == posbatch).Single().Ilosc = posq; foreach(var pozr in r.Pozycje.Where(p => p.PartiaZrodlowa.Id != posbatch && p.Ilosc > 0m)) { pozr.Ilosc = 0m; } foreach(var pozr in r.Pozycje.Where(p => p.PartiaZrodlowa.Id != 0 )) { Console.WriteLine("Wybrane partie: "+pozr.PartiaZrodlowa.Id+" = "+pozr.Ilosc); } r.ZakonczRozbicie(); aplikatorSM.AplikujSkutkiMagazynowe(poz); // ponowna poprawka na poprawne rozbicie } else { poz.Ilosc = posq; // ustawiamy na 0, wyjdzie z rozbicia aplikatorSM.AplikujSkutkiMagazynowe(poz); } } // wypełnienie pozycji na podstawie asortymentu foreach(var posadd in results.posextra) { int posid; decimal posq; posid = posadd.id; posq = posadd.quantity; Asortyment a = asortyment.Dane.Wszystkie().Where(t => t.Id == posid).First(); var poz = wz.Pozycje.Dodaj(a,posq, a.JednostkaSprzedazy); Console.WriteLine("Dodanie pozycji dodatkowej: "+poz.AsortymentAktualny.Nazwa); // jeśli jest opis pozycji if(posadd.desc!=null && posadd.desc!="") { string posd; posd = posadd.desc; poz.Opis = posd; } // jeśli jest cena pozycji if(posadd.price!=null) { decimal posp; posp = posadd.price; poz.Cena.NettoPoRabacie = posp; } wz.Przelicz(); } // poprawka na nabywcę if(wz.Dane.NabywcaSprzedawca==null) { wz.Dane.NabywcaSprzedawca = wz.Dane.Podmiot; wz.Dane.RolaInnegoPodmiotu = (byte)RolaInnegoPodmiotu.InnyNabywca; } // ustawienie daty if(results.date!=null && results.date!="") { string dateString = results.date+" 07:00:00,000"; DateTime wzDate = DateTime.ParseExact(dateString,"yyyy-MM-dd HH:mm:ss,fff",System.Globalization.CultureInfo.InvariantCulture); wz.Dane.DataWydaniaWystawienia = wzDate; wz.Dane.DataWprowadzenia = wzDate; Console.WriteLine("Data wystawienia: " + wzDate); } // dopisanie transportu, jeśli jest decimal transport; transport = results.transport; if(transport!=0) { Asortyment a = asortyment.Dane.Wszystkie().Where(t => t.Symbol == "U Transport").First(); var poz = wz.Pozycje.Dodaj(a, 1m, a.JednostkaSprzedazy); poz.Cena.NettoPoRabacie = transport; } // osoba wystawiająca string sign = results.sign; wz.Dane.WystawilaOsoba = uzytkownicy.Dane.Wszystkie().Where(p => p.Sygnatura == sign).FirstOrDefault().Osoba; wz.Dane.Uwagi = results.comment; Link to postu
Mateusz Matuszewski 91 Napisano 12 Sierpnia 2021 Udostępnij Napisano 12 Sierpnia 2021 w [Sfera] Adres dostawy na WZ, inny niż na ZK, od wersji 36 W wersji 36 były robione poprawki z przenoszeniem adresu dostawy na dokument realizujący. Proszę spróbować zrealizować zamówienie bez ręcznego ustawiania w parametrach grupowania pól MiejsceDostawy oraz MiejsceDostawyTyp, wtedy adres powinien zostać przeniesiony automatycznie. 1 Link to postu
Radomił Ząbik 308 Napisano 23 Sierpnia 2021 Autor Udostępnij Napisano 23 Sierpnia 2021 w [Sfera] Adres dostawy na WZ, inny niż na ZK, od wersji 36 Wygląda na to, że rzeczywiście to było problemem, bo już od tygodnia nie mam zgłoszeń, aby problem się pojawiał. Dziękuje. Link to postu
Radomił Ząbik 308 Napisano 7 Września 2021 Autor Udostępnij Napisano 7 Września 2021 w [Sfera] Adres dostawy na WZ, inny niż na ZK, od wersji 36 Jeszcze wrócę do tematu - czy w związku z tymi zmianami, mogła spaść wydajność takiego procesu jak u mnie? Przeglądam logi, to przed aktualizacją, niektóre proste WZ wystawiały się nawet w sekundę, a teraz uzyskanie 3 sekund jest dobrym wynikiem. Serwer się nie zmienił, ani sam kod poza zmianą powyżej też nie. Link to postu
Mateusz Matuszewski 91 Napisano 13 Września 2021 Udostępnij Napisano 13 Września 2021 w [Sfera] Adres dostawy na WZ, inny niż na ZK, od wersji 36 Adres dostawy nie powinien mieć większego wpływu na wydajność. Czy problem dotyczy tylko dokumentów na których jest przepisywany adres dostawy czy raczej ogólnie? Jaka była wersja programu przed aktualizacją? Link to postu
Radomił Ząbik 308 Napisano 13 Września 2021 Autor Udostępnij Napisano 13 Września 2021 w [Sfera] Adres dostawy na WZ, inny niż na ZK, od wersji 36 Odnotowaliśmy wolniejsze działanie naszej aplikacji, wykonującej zadania w Sferze, które trochę pokrywa się z przejściem z wersji 35.1.0 na 36.0.1. Póki co cały czas szukam przyczyny, czemu w szczególności to zadanie Sferyczne, pochłania najwięcej czasu, co przez kolejkowanie wykonywanych Sferycznie zadań, trochę przytyka nam nasz system. Przeglądając logi, w niektórych przypadkach, skok jest 2x, np. przy 20 pozycjach. Dlatego pytam, czy nie zmienialiście tutaj czegoś jeszcze, bo może akurat coś wpłynęło na nasz kod. Z tego co sprawdzałem, to kluczowa jest ta część poniżej - tutaj po prostu muli, a pamiętam czasy, że leciało jak szalone - mamy pełną licencję SQL'a od was, postawioną na świeżutkiej maszynie z 128GB RAM (którego ostatnimi czasy SQL też potrafił pochłonąć). A może już wielkość bazy stanowi problem, aczkolwiek taki skok w ciągu miesiąca jest dziwny. if(posadd.batch!=null) { poz.Ilosc = 0; // ustawiamy na 0, wyjdzie z rozbicia aplikatorSM.AplikujSkutkiMagazynowe(poz); // poprawka od Insertu na poprawne działanie skutku magazynu var r = dok.RozpocznijRozbicie(poz) as IRozbiciePozycjiRozchodowe; Console.WriteLine("Wprowadzenie partii: "+posbatch+" w ilości "+posq); r.Pozycje.Where(p => p.PartiaZrodlowa.Id == posbatch).Single().Ilosc = posq; foreach(var pozr in r.Pozycje.Where(p => p.PartiaZrodlowa.Id != posbatch && p.Ilosc > 0m)) { pozr.Ilosc = 0m; } foreach(var pozr in r.Pozycje.Where(p => p.PartiaZrodlowa.Id != 0 )) { Console.WriteLine("Wybrane partie: "+pozr.PartiaZrodlowa.Id+" = "+pozr.Ilosc); } r.ZakonczRozbicie(); aplikatorSM.AplikujSkutkiMagazynowe(poz); // ponowna poprawka na poprawne rozbicie } else { poz.Ilosc = posq; // ustawiamy na 0, wyjdzie z rozbicia aplikatorSM.AplikujSkutkiMagazynowe(poz); } Link to postu
Mateusz Matuszewski 91 Napisano 14 Września 2021 Udostępnij Napisano 14 Września 2021 w [Sfera] Adres dostawy na WZ, inny niż na ZK, od wersji 36 (edytowane) Sprawdziłem u siebie i faktycznie wygląda na to, że pomiędzy wersjami rozbicie spowolniło o około 50%. Będziemy to analizować, dam znać w tym temacie jak tylko uda się coś ustalić. EDIT: Po ponownym sprawdzeniu okazało się, że jednak żadnego spowolnienia nie było, a nawet w 36.0.1 jest trochę szybciej. Może różnica wynika z ilości dostępnych partii? Edytowane 14 Września 2021 przez Mateusz Matuszewski Błąd pomiaru Link to postu
Radomił Ząbik 308 Napisano 14 Września 2021 Autor Udostępnij Napisano 14 Września 2021 w [Sfera] Adres dostawy na WZ, inny niż na ZK, od wersji 36 3 godziny temu, Mateusz Matuszewski napisał: Może różnica wynika z ilości dostępnych partii? W sensie globalnie system może zacząć się z biegiem czasu zapychać, czy chodzi o dostępne partie dla danego wydania? No jeśli wy potwierdzacie, że u was jest spoko i nie widzi Pan tutaj jakiś błędów z mojej strony, które mogły by zamulać, no to szukamy dalej - może to jakiś problem sieciowy, firmware, albo jakiś Windows Update Link to postu
Mateusz Matuszewski 91 Napisano 14 Września 2021 Udostępnij Napisano 14 Września 2021 w [Sfera] Adres dostawy na WZ, inny niż na ZK, od wersji 36 10 minut temu, Radomił Ząbik napisał: W sensie globalnie system może zacząć się z biegiem czasu zapychać, czy chodzi o dostępne partie dla danego wydania? Chodzi o partie dostępne dla danego wydania. W wersji 36 nie było żadnych zmian w tej okolicy, ale wersja 37 będzie zawierała kilka poprawek wydajnościowych, więc po aktualizacji powinno trochę przyspieszyć. 1 Link to postu
Radomił Ząbik 308 Napisano 16 Września 2021 Autor Udostępnij Napisano 16 Września 2021 w [Sfera] Adres dostawy na WZ, inny niż na ZK, od wersji 36 To znowu ja, już się Pan cieszy Dobra wiadomość jest taka, że najwidoczniej gdy podczas aktualizacji, restartowaliśmy system, Windows Server postanowił Sobie wprowadzić jakieś magiczne ustawienia oszczędzania energii, dla SQL'a (po 3 miesiącach pracy), przez co SQL dostawał czkawki i stąd całe problemy wydajnościowe. Przepraszam za zawracanie gitary, zwróciłem uwagę najpierw na zmianę wersji programu. Zła jest taka, że przenoszenie adresów działa, poza jednym wyjątkiem - jeśli na ZK jest ustawiony adres Zamawiającego, który pochodzi z Adresy dodatkowe ustawionego na podmiocie. Efekt jest taki: ZK: WZ: Adres, który wskoczył na WZ, także jest adresem dodatkowym podmiotu, ale jest oznaczony jako podstawowy. Link to postu
Mateusz Matuszewski 91 Napisano 16 Września 2021 Udostępnij Napisano 16 Września 2021 w [Sfera] Adres dostawy na WZ, inny niż na ZK, od wersji 36 1 godzinę temu, Radomił Ząbik napisał: Windows Server postanowił Sobie wprowadzić jakieś magiczne ustawienia oszczędzania energii, dla SQL'a (po 3 miesiącach pracy), przez co SQL dostawał czkawki i stąd całe problemy wydajnościowe Cieszę się, że się wyjaśniło. 1 godzinę temu, Radomił Ząbik napisał: Adres, który wskoczył na WZ, także jest adresem dodatkowym podmiotu, ale jest oznaczony jako podstawowy. Prawdopodobną przyczyną jest ustawianie nabywcy po wypełnieniu WZ, ponieważ wtedy adres dostawy zmienia się na domyślny. Rozwiązanie tego problemu mamy zapisane na dalszą przyszłość. if(wz.Dane.NabywcaSprzedawca==null) { wz.Dane.NabywcaSprzedawca = wz.Dane.Podmiot; wz.Dane.RolaInnegoPodmiotu = (byte)RolaInnegoPodmiotu.InnyNabywca; } Zamiast tego proszę spróbować ustawić pole NabywcaSprzedawca w parametrach grupowania: parametryGrupowania.NabywcaSprzedawca = zk.NabywcaSprzedawcaWybrany ?? zk.PodmiotWybrany; Link to postu
Polecane posty