Paweł Kubacki

Najlepiej wykorzystać nową metodę DodajPlatnosciDomyslne zk.Platnosci.DodajPlatnosciDomyslne();

Obecnie jest to kolekcja o nazwie "DomyslneFormyPlatnosci".

Tak. Była o tym mowa w wątku

Dokładnie tak, wskoczą w tabelkę płatności domyślnych. Inaczej mówiąc jeżeli w poprzedniej wersji określono w kliencie, że dokumenty będą miały domyślnie odroczoną płatność, to po konwersji w nowej wersji także tak będzie.

Domyślna forma kredytu kupieckiego przeniesie się jako płatność domyślna z takim procentem jaki był wcześniej wpisany w domyślny kredyt kupiecki. Indywidualny termin płatności dla sprzedaży i zakupu to nowość wersji 35. Pozwala on na ustawienie różnym klientom różnych terminów płatności bez konieczności tworzenia wielu form płatności. Nie ma sensu przepisywać termin płatności określony w formie płatności do tych ustawień klienta. Jeżeli klient nie ma ustawionych tych wartości, to wówczas termin płatności będzie i tak wyznaczany na podstawie ustawień formy płatności.

Kredyt kupiecki to inaczej płatność odroczona. Można to zrobić w ten sposób: ds.Platnosci.DodajPlatnoscOdroczona(...);

Można to zrobić np. tak: ds.Platnosci.DodajPrzedplate(operacjaBankowa.Rozrachunek.Pozycje.Single(), 40);

Kurs będzie ustalany według wyżej widocznych parametrów także dla dokumentów dodawanych przy pomocy sfery. Domyślnie jest to dzień poprzedzający wystawienie dokumentu. Ważna jest więc data wpisana jako data wystawienia dokumentu (DataWprowadzenia) a nie moment, w którym rozwiązanie sferyczne będzie uruchamiane.

KursWalutyDokumentu jest to encja przynależąca do danych dokumentu. Każdy dokument w walucie ma własną instancję tej klasy. Pobierając tą daną przy użyciu metody FirstOrDefault w taki sposób var kurs = linieKursow.Dane.PobierzKursNaDzien(linia, walutyDef.EUR, walutyDef.PLN, DateTime.Now).KursyWalutyDokumentu.FirstOrDefault(); w rzeczywistości pobiera Pani instancję KursWalutyDokumentu przynależącą do jakiegoś innego wcześniej wystawionego dokumentu. Stąd też przy zapisie pojawia się błąd. Aby prawidłowo ustawić kurs na dokumencie walutowym wystarczy wykonać taki kod var kurs = linieKursow.Dane.PobierzKursNaDzien(linia, walutyDef.EUR, walutyDef.PLN, DateTime.Now); ... zk.Dane.Waluta = walutyDef.EUR; zk.Dane.KursWalutyDokumentu.TabelaKursowWalutPozycja = kurs; Przy czym ważne jest, aby najpierw ustawić walutę, a potem dopiero kurs, gdyż po zmianie waluty program sam stworzy instancję klasy KursWalutyDokumentu i wypełni ją według ustawień programu. Zastanawia mnie jednak dlaczego w ogóle chce Pani ręcznie podmieniać domyślnie ustawiony kurs waluty? W programie istnieje dosyć rozbudowana konfiguracja pozwalająca ustalić według jakich kryteriów kurs na dokumencie ma być ustalany.

Drodzy Państwo w wersji wiosennej planujemy wprowadzić wiele zmian dotyczących płatności na dokumentach Subiekta. Jest to pierwszy etap prac, który będzie kontynuowany w kolejnych wersjach. Większość zmian nie powinna wpłynąć na pracę dotychczas stworzonych rozszerzeń wykorzystujących Sferę nexo. Jednak jest kilka takich, które mogą wymagać zmian w rozwiązaniach własnych. Pierwszą z takich zmian jest konfiguracja płatności, która przeszła dużą metamorfozę. Przykładowo parametry decydujący o tym czy na dokumencie powinny być widoczne sekcje dotyczące przedpłat i pozostałych płatności zostały zastąpione znanym od kilku wersji mechanizmem ustawiania widoczności pól. To tylko jedna z przykładowych zmian. Jednak jeżeli w swoich rozwiązaniach sferycznych nie odczytywaliście lub zmienialiście Państwo parametrów dotyczących płatności, to te zmiany mimo, że poważne nie powinny mieć wpływu na te rozwiązania. Drugą zmianą, której nie udało się zachować kompatybilności jest realizacja dokumentów, która w pewnych przypadkach wymagała przepisania płatności na dokument realizowany w swoim rozwiązaniu własnym. Jeżeli korzystaliście Państwo ze sposobu opisanego w tym wątku na forum to w wersji wiosennej rozwiązanie takie będzie wymagało modyfikacji. Od wersji wiosennej przy realizacji dokumentów płatności zawsze będą się przepisywać (jeżeli tak określono w parametrach realizacji, klasa ParametryGrupowaniaPodstawowe i wszystkie jej pochodne). Zamieszczony w tym wątku kod będzie więc od tego momentu zbędny. Wydaje się też, że można łatwo przygotować się na okres przejściowy dodając już teraz jedną linijkę kodu jako pierwszą instrukcję po „if” przed przepisywaniem płatności w postaci: zk.PlatnosciDokumentow.Clear(); Zapobiegnie ona dublowaniu płatności przy realizacji po wyjściu nowej wersji programu. Trzecia zmiana może mieć największy wpływ na Państwa rozwiązania własne. Od wersji wiosennej możliwe będzie określenie dowolnych i wielu domyślnych form płatności klienta. W związku z tym zmieni się sposób określania domyślnej płatności klienta oraz zezwolenia na kredyt kupiecki. Oto przykładowy kod dotyczący tych ustawień w obecnej i przyszłej wersji programu: 1. Zezwolenie na kredyt kupiecki i ustawienie domyślnie 60% dla tej formy płatności Stary sposób: podmiot.DomyslnaFormaKredytuKupieckiego = przelew7dni; podmiot.DomyslnyKredytKupiecki = 0.6; Nowy sposób: podmiot.ZezwalajNaKredytKupiecki = true; var domyslnaFormaPlatnosci = new FormaPlatnosciPodmiotu(); podmiot.DomyslneFormyPlatnosci.Add(domyslnaFormaPlatnosci); podmiot.FormaPlatnosci = przelew7dni; podmiot.Procent = 60; 2. Zablokowanie kredytu kupieckiego Stary sposób: podmiot.DomyslnaFormaKredytuKupieckiego = null; Nowy sposób: podmiot.ZezwalajNaKredytKupiecki = false;

Najprostszym rozwiązaniem jest przekazanie dodatkowych parametrów do metody Wszystkie, które pozwolą załadować wszystkie dane jednym zapytaniem. Wówczas podczas iteracji dane nie będą musiały być doładowywane. IEnumerable<Asortyment> wszystkie = menedzerAsortymentow.Dane.Wszystkie("PozycjeCennika.Cennik.PoziomCen", "PodstawowaJednostkaMiaryAsortymentu.KodyKreskowe"); Jednak można to zoptymalizować jeszcze bardziej. Proszę zauważyć, że z wszystkich danych asortymentu potrzebna jest jedynie nazwa. Można więc stworzyć zapytanie, które wczyta jedynie te dane, które są konieczne. using (var sfera = UruchomSfere()) { IAsortymenty menedzerAsortymentow = sfera.PodajObiektTypu<IAsortymenty>(); var wszystkie = menedzerAsortymentow.Dane.Wszystkie().Select(x => new { x.Nazwa, Cena = x.PozycjeCennika.Where(a => a.Cennik.PoziomCen.Nazwa == "Detaliczny").Select(pc => pc.CenaBrutto).FirstOrDefault(), Kody = x.PodstawowaJednostkaMiaryAsortymentu.KodyKreskowe.Select(k => k.Kod), }); foreach (var towar in wszystkie) { var cena = Decimal.ToInt32(towar.Cena * 100); foreach (var kod in towar.Kody) { var linia = towar.Nazwa + " " + kod + " " + cena; Console.WriteLine(linia); } } }

Nie uda się dopisać pozycji do AKC_PozycjeDokumentu z Id, którego nie ma w tabeli PozycjeDokumentu. Tak samo nie udałoby się usunięcie pozycji z PozycjeDokumentu bez usuwania skojarzonego wpisu w AKC_PozycjeDokumentu.

Trochę się pogubiłem. To jak długo się wykonuje to zapytanie, które stwarza problemy? Te czasy, które Pan do tej pory podał nie wskazują na problemy wydajnościowe. Każdy JOIN wydłuża czas wykonania zapytania, więc to, że akurat po połączeniu z własną tabelą zapytanie nieco spowolniło to nic dziwnego. Proszę rozwinąć tą myśl, gdyż nic nie wiem o tym programie, z którego Pan korzysta. Jeżeli problem jest widoczny w jakimś zewnętrznym programie, a takie samo zapytanie wykonywane z poziomu Management Studio wykonuje się szybko, to warto sprawdzić profilerem SQL co ten program rzeczywiście wysyła do SQLa.

Tak niestety przypuszczałem. Proszę sprawdzić czy i jakie indeksy są założone na tą własną tabelę. Proszę też przesłać warunek łączenia pozycji dokumentu z tą własną tabelą w Pana raporcie.

Jeżeli chce Pan wprowadzić FOREIGN KEY do swojej tabeli, to niestety nie mogą wisieć. Prawdopodobnie to właśnie te wiszące pozycje uniemożliwiają założenie klucza obcego. Należałoby więc zrobić dwie rzeczy. Pierwsza to wyczyszczenie wszystkich wiszących pozycji, które nie mają już swojego odwzorowania w pozycjach dokumentów. Druga to zapewnienie aby przy usuwaniu pozycji dokumentu były też usuwane pozycje z Pana tabeli. W przeciwnym przypadku może przestać działać usuwanie pozycji na dokumentach i usuwanie dokumentów. Powinno pomóc ustawienie ON DELETE CASCADE. Samo wprowadzenie FOREIGN KEY może być niewystarczające. Jednak o tym za chwilę. Proszę najpierw wprowadzić ten klucz obcy i sprawdzić czy działa usuwanie pozycji i całych dokumentów. Proszę też zweryfikować czy po wprowadzeniu klucza obcego cokolwiek się zmieniło w wydajności tych zapytań.

Proponuję umieszczenie odpowiedniej metody w kodzie wydruku (zakładka Code). Metoda ta mogłaby wyglądać np. tak: public string PrzetlumaczFormePlatnosci(string formaPlatnosci) { switch (formaPlatnosci) { case "Gotówka": return "Cach"; case "Przelew": return "Bank transfer"; } // Dla form płatności nieuwzględnionych zwracana jest nazwa oryginalna. return formaPlatnosci; } Tak stworzoną metodę można wykorzystać wówczas wszędzie tam, gdzie są odwołania do nazwy formy płatności.

Proszę w takim razie pokazać jak to wygląda w programie. Poproszę o zrzuty ekranu takiego przykładowego ZK, operacji bankowej oraz faktury wystawianej do tego ZK. Interesuje mnie głównie sekcja prezentująca płatności, a na operacji bankowej sekcja rozliczenia i przedpłaty. Sądziłem, że powiązanie przelewu z ZK/FS odbywa się poprzez przedpłaty. Jednak na standardowym wydruku dokumentu przy przedpłatach prezentowana jest informacja o dacie wpłaty. Potrzebuje więc uzyskać więcej informacji o sposobie powiązania tych dokumentów.

A jak są wiązane te operacje w wystawianą FS? Mógłbym zobaczyć kawałek kodu, który to wiąże? Może Pan to przesłać w wiadomości prywatnej.

A jak te płatności są wiązane z FS, jako przedpłaty? Czy chodzi tylko o wydrukowanie daty wpływu środków dla tych przedpłat, czy także dla późniejszych płatności, np. dokonanych tydzień po wystawieniu dokumentu?

W razie wątpliwości proszę śmiało pytać. Nie wiem też czy bardziej interesuje Pana data rozliczenia, czy data wpłaty za fakturę. Data rozliczenia jest zawsze większą z tych dwóch dat. Jeżeli więc środki wpłynęły przed wystawieniem FS, to data rozliczenia nie będzie datą wpływu środków.

A w jakiej formie taka informacja miałaby być drukowana, jako osobna sekcja, czy gdzieś przy płatnościach? Czy miałaby uwzględniać jedynie płatności dokonane przy wystawianiu dokumentu, czy także te późniejsze już po jego wystawieniu? Jeżeli na wydruku mają być ujęte wszystkie rozliczenia w osobnej sekcji, to najłatwiej byłoby dodać do encji dokumentu obiekt rozrachunek, do niego pozycję, później pozycję rozliczenia i samo rozliczenie.

Ciężko jest stwierdzić czemu taki problem w Pana rozwiązaniu wystąpił. Sesje aplikacyjne mają dosyć długi czas ważności. Z tego co pamiętam to żyją 6 minut. Wygląda więc to tak jakby od czasu utworzenia dokumentu do czasu jego zapisu minęło ponad 6 minut. Czy komputer na którym jest uruchomione to rozwiązanie nie był przypadkiem na pewien czas uśpiony? Zwykle to bywało przyczyną tego typu problemów.

W jakiej sytuacji wystąpił ten błąd? Czy w trakcie pracy z programem, czy może jest to jakieś rozwiązanie oparte na sferze?

Jest pewna możliwość obejścia tego problemu. Skontaktujemy się z Panem w tej sprawie.

Problem został poprawiony do wersji 26.1.0, która jest już dostępna.