Paweł Kubacki

Jasne, ale dalej nie napisał Pan o której liście rozmawiamy. Zakładam jednak, że chodzi o tą z konfiguracją własnych kolumn. Jednak jak widać na załączonym obrazku (rys. 1) kolumny są tam pogrupowane po nazwie raportu. Czy to nie wystarcza? Rys. 1 Czy ma Pan na myśli okno widoczne powyżej (rys. 1)? Zgadza się, jeżeli raport ma być źródłem własnych kolumn, to powinien mieć unikalne nazwy w obrębie ewidencji/raportów związanych z głównym elementem. Natomiast nie każdy raport musi być źródłem własnych kolumn. O tym czy kolumny z raportu będą widoczne w konfiguracji widoku (rys. 3) decyduje poniższy znacznik (rys. 2). Rys. 2 Tutaj słowa wyjaśnienia wymaga to, co widać w konfiguracji własnych kolumn, czyli po naciśnięciu tego przycisku Rys. 3 W oknie, które się wówczas pojawia (rys. 1) widać kolumny ze wszystkich własnych raportów. Gdy wybierze się jedną z nich, to wówczas cały raport, z którego pochodzi ta kolumna, staje się źródłem własnych kolumn i kolumny pochodzące z tego raportu będą widoczne w konfiguracji widoku (rys. 3). Nie przewidujemy takiej opcji. Jedyna możliwość usunięcia kolumny z konfiguracji widoku, to wyłączenie parametru widocznego na rys. 2. Raporty z kolumnami własnymi są dopasowywane do wbudowanych serwisów i raportów po pasującym elemencie głównym. Oznacza to, że kolumna dodana w widoku Asortyment będzie widoczna także w raportach prezentujących asortyment. Pisałem o tym w tym poście.

W którym miejscu? Obecnie tak to właśnie działa, że po zmianie nazwy kolumny, jej oryginalna nazwa (z raportu) wyświetlana jest w nawiasie. Nazwa raportu nie może być tam prezentowana, bo jeden raport może tworzyć wiele kolumn. Taka zmiana dla wszystkich użytkowników może być wykonana od strony raportu własnego. Stara nazwa kolumny jest widoczna do momentu zamknięcia zakładki, na której uruchomiono dany serwis. Po zamknięciu zakładki i ponownym uruchomieniu serwisu w nowej zakładce, problem nie powinien już występować, a w nagłówku kolumny powinna pojawić się nowa nazwa. Zapisałem sugestię.

Temat dalej czeka w kolejce i w najbliższej przyszłości nie planujemy jego realizacji.

Dziękuje za przesłane dane. Udało się nam namierzyć problem, który powodowały stworzone dawno temu raporty własne. W jednej z kolejnych wersji zabezpieczymy się przed takimi przypadkami. Natomiast gdyby ktoś natrafił na podobny problem, to obejściem jest wejście w edycję każdego z raportów własnych i ponowne jego zapisanie.

Proszę na stanowisku, gdzie wystąpił ten problem oraz na tej konkretnej bazie danych wygenerować dane diagnostyczne i przesłać je do mnie w wiadomości prywatnej.

Dziękuje za uszczegółowienie. Temat własnych kolumn na listach edycyjnych będziemy realizować w jednej z przyszłych wersji programu.

To jeszcze dopytam co chciałby Pan dodać na tej liście pozycji i czy zawartość nowej kolumny ma być edytowana, czy tylko do odczytu?

Proszę zamieścić zrzut ekranu, gdzie chciałby Pan takie własne kolumny dodać?

Samego powielania użytkowników nie ma w programie. Jednak można na podstawie wybranego użytkownika utworzyć rolę zawierającą uprawnienia tego użytkownika. Tak utworzoną rolę można następnie przypisać nowemu użytkownikowi.

Wraz z wersją 50 nexo wprowadzamy możliwość tworzenia własnych kolumn, które mogą być wykorzystane we wbudowanych serwisach oraz raportach. Aby skorzystać z tych możliwości należy w pierwszej kolejności uruchomić serwis Laboratorium wybierając go z listy serwisów lub za pomocą skrótu Ctrl+Spacja, a następnie XX. Następnie należy zaakceptować regulamin Laboratorium jeżeli dotychczas nie był zaakceptowany. W tym momencie można już włączyć własne kolumny. Własne kolumny można tworzyć na jeden z dwóch sposobów. Tworzenie własnych kolumn za pomocą raportów SQL lub LINQ. Tworzenie własnych kolumn za pomocą raportów własnych wymaga znajomości składni zapytań SQL bądź LINQ oraz znajomości struktury bazy danych programu. Aby utworzyć własną kolumnę w taki sposób należy uruchomić dany widok, a w nim konfigurację widoku. W pierwszej zakładce pod listą kolumn dostępny jest przycisk służący do dodawania własnych kolumn, należy go kliknąć. Pojawi się wówczas nowe okno, w którym do wyboru będą dwa rodzaje raportów. Należy kliknąć w jeden z tych przycisków. Tworząc raport własny należy podać wszystkie wymagane informacje, w tym główny element, na podstawie którego tworzony jest raport. Należy także podać treść zapytania, a później nacisnąć przycisk do synchronizacji kolumn. Jeżeli raport jest poprawny i wykonano synchronizację kolumn, to można taki raport zapisać. W oknie z konfiguracją własnych kolumn pojawią się wówczas nowe kolumny, utworzone za pomocą raportu własnego. W oknie tym można wybrać, które z nowo dodanych kolumn chcemy uwidocznić. Po dokonaniu wyboru należy kliknąć przycisk OK. Na końcu należy jeszcze zapisać tak zmienioną konfigurację widoku. Po utworzeniu nowych kolumn za pomocą raportów własnych, nowe kolumny będą dostępne do wyboru w konfiguracji widoku na liście kolumn. Można także skorzystać z nich do grupowania wierszy oraz formatowania warunkowego. Tworzenie własnych kolumn przy pomocy raportów własnych zostało także zaprezentowane w filmie przedstawiającym nowości wersji 50 nexo. Warto jeszcze wspomnieć, że kolumny dodawane w jednym widoku, mogą być także wykorzystane w innych widokach. Kojarzenie raportu własnego z wbudowanym widokiem odbywa się na podstawie wybranego głównego elementu. Kolumny utworzone raportem własnym opartym na głównym elemencie "Asortyment", będą dostępne do wyboru nie tylko w raporcie "Asortyment niechodliwy", ale także w pozostałych raportach opartych na asortymencie oraz w serwisie "Asortyment". Tworzenie własnych kolumn za pomocą sfery Ten sposób tworzenia własnych kolumn wymaga znajomości języków programowania. Szczegółowy opis tworzenia własnych kolumn za pomocą sfery znajduje się w pomocy do sfery w dziale dotyczącym rozszerzania aplikacji. W naszym SDK do wersji 50 w katalogu z przykładami znajduje się także przykładowy projekt o nazwie RozszerzeniaListDanych, w którym zaprezentowano przykładowy kod tworzący własne kolumny.

W wersji 50 nie będzie jeszcze aktualizacji Stimulsoft, ale planujemy w tym roku zaktualizować tą bibliotekę.

Można osiągnąć taki efekt, ale jedynie po stronie klienta, a nie serwera SQL. Oznacza to, że zapytanie musi być wcześniej wykonane, co można osiągnąć np. za pomocą funkcji ToList. Poniżej przykład zapytania z numerem LP w raporcie własnym LINQ opartym na asortymencie. null; var queryZmaterializowane = source .Select((Asortyment asortyment) => new { Id = asortyment.Id, Nazwa = asortyment.Nazwa, Symbol = asortyment.Symbol }).ToList(); int lp = 1; result = queryZmaterializowane .Select(x => new Wynik { Lp = lp++, Id = x.Id, Nazwa = x.Nazwa, Symbol = x.Symbol }).AsQueryable(); Alternatywnym rozwiązaniem jest wykorzystanie raportu SQL i wyrażenia ROW_NUMBER. Wówczas całe zapytanie będzie wykonywane po stronie serwera.

Zapisałem sugestię. Jest pewna szansa, że zostanie zrealizowana przed wersją 80-tą, ale na ten moment nie mogę podać konkretnej wersji.

Dziękuje za zgłoszenie. Zapisaliśmy do poprawy.

W wersji 50.0.0 nexo planujemy wprowadzić zmianę w sferze we własnych operacjach w menu, która złamie dotychczasowy kontrakt. W klasie dziedziczącej po OperacjaNaLiscieDanych<Pracownik, int>, czyli własnych operacjach na liście pracowników, w metodzie void Wykonaj(IReadOnlyCollection<int> identyfikatoryWybranychElementow, IKontekstListyDanych kontekstListyDanych, IKontekstOperacji kontekstOperacji) zmieni się pierwszy parametr - lista identyfikatorów wybranych na liście elementów. Dotychczas przekazywane do niej były identyfikatory encji Podmiot. Od wersji 50 przekazywane będą identyfikatory encji Pracownik. Niestety nie jesteśmy w stanie wprowadzić tej zmiany w etapach, dlatego ostrzegamy aby klienci, którzy posiadają rozszerzenia (własne operacje wykonywane na pracowniku) nie instalowali wersji 50 przed dostosowaniem tych rozszerzeń do nowej wersji programu.

W tym temacie nic się nie zmieniło. Dalej polecamy wykonanie takiego testu, który można zrobić na kopii podmiotu. Przy czym należy się liczyć z co najmniej jednym problemem. Wielkość pliku kopii bezpieczeństwa z pewnością mocno wzrośnie. Sam podgląd nie wystarczy. Trzeba jeszcze uwzględnić możliwość użycia zdjęcia w opisie towaru, w naklejkach, możliwość wysłania oferty internetowej do allegro, kwestie wyświetlania zdjęć w kolumnie w serwisie asortymentu i być może jeszcze parę innych miejsc w programie. Nie należy liczyć, że w pierwszej połowie tego roku pojawi się taka możliwość. Czy pojawi się w drugiej połowie, na ten moment nie jestem w stanie określić.

Temat przechowywania zdjęć poza bazą danych mamy na uwadze. Jednak na dzień dzisiejszy nie jestem w stanie podać terminu realizacji.

Okno parametrów będzie działało dopiero po zalogowaniu do sfery. W tym przypadku trzeba więc posłużyć się własnym oknem.

Instrukcja jest ogólna, ale przedstawiony w pierwszej wiadomości przykład dotyczył dodania pól własnych klienta na wydruk FS. W przypadku asortymentu ścieżka prowadząca do pól własnych będzie inna. Tutaj chciałbym zwrócić uwagę, że jest to instrukcja techniczna. Została stworzona z myślą o osobach zajmujących się wdrażaniem/serwisowaniem aplikacji. Polecam zatem skorzystać z pomocy takiej osoby. Proszę przejrzeć naszą listę serwisantów.

W jaki sposób przystosowuje Pan swoje rozwiązanie sferyczne do nowej wersji nexo? Czy przypadkiem nie wgrywa Pan bibliotek z nowej wersji SDK do katalogu, gdzie wcześniej były biblioteki z poprzedniej wersji?

Proszę zamieścić pełny komunikat błędu, bo niestety brakuje jego najistotniejszej części. Czy w Pańskim rozwiązaniu wykorzystywane są jakieś biblioteki, z których korzysta także nexo?

Czy nie pisze Pan przypadkiem o tym?

Problemem jest tutaj przekazywanie encji rozrachunku z załadowanego dokumentu sprzedaży do metody tworzącej obiekt rozrachunku. W zasadzie wystarczy drobna zmiana w Pana kodzie, aby odizolować oba obiekty od siebie i aby ten plugin działał. ... using (var rch = rozrachunki.Znajdz(x => x.Id == rozrachunek.Id)) { ... } Jednak sugeruję nieco większą zmianę ze względu na wydajność. Dokument sprzedaży jest dość złożonym obiektem i bez potrzeby nie warto powoływać go do życia. W tym przypadku dokument ten nie jest zmieniany, pobierane są z niego jedynie uwagi, więc proponuję następującą zmianę. public override void PoZapisieObiektu(IKontekstZdarzeniaPoZapisieObiektu<IDokumentSprzedazy> kontekst) { if (kontekst.StanZapisanegoObiektu == StanZapisanegoObiektu.Dodany) { IDokumentySprzedazy sprzedaz = kontekst.Uchwyt.PodajObiektTypu<IDokumentySprzedazy>(); IRozrachunki rozrachunki = kontekst.Uchwyt.PodajObiektTypu<IRozrachunki>(); int idZapisanegoDokumentu = (int)kontekst.IdDanych; var uwagi = sprzedaz.Dane.Wszystkie() .Where(x => x.Id == idZapisanegoDokumentu) .Select(x => x.Uwagi) .FirstOrDefault(); using (var rch = rozrachunki.Znajdz(x => x.Dokument.Id == idZapisanegoDokumentu)) { if (rch.Zablokuj()) { rch.Odblokuj(); rch.Dane.Tytul = uwagi; if (rch.Zapisz()) { } else rch.WypiszBledy(); } } } } Nadmiarowy wydaje mi się także kod związany z blokowaniem obiektu.

Jeżeli użytkownik jest nowy i nie ma jeszcze spersonalizowanych widoków, to nie trzeba niczego usuwać. W tabeli WidokiSerwisowe nie będzie wówczas dla niego żadnych wpisów. Jeżeli natomiast jakieś widoki już dostosowywał do swoich potrzeb, to może nie warto mu ich zmieniać. Proszę zwrócić uwagę, że podane przez Pana polecenie usuwa wszystkie widoki użytkownika bez względu na to jakie widoki będą potem w drugim kroku kopiowane z wzorcowego użytkownika. Może się więc zdarzyć, że usunięta zostanie zmieniona konfiguracja np. serwisu Asortyment mimo, że użytkownik wzorcowy nie dokonał zmian w tej konfiguracji i nie będzie ona w kroku 2 skopiowana. W rezultacie konfiguracja tego serwisu wróci do ustawień domyślnych. Pola TimeStamp i Naglowek_Id nie powinny być kopiowane.

W programie jest możliwość eksportu/importu ustawień widoku. Gdyby jednak chciał Pan przenieść ustawienia list edycyjnych, np. pozycji faktury, to tam jeszcze nie ma takiego importu/eksportu. Ustawienia widoku przechowywane są w tabeli WidokiSerwisowe, a ustawienia list edycyjnych w tabeli StanyAplikacji.