Znajdź zawartość

Witam, Problem 1 Jak posługiwać się nowo wprowadzonym rodzajem parametru zakres dat? W dokumentacji nie ma jeszcze żadnego przykładu,a w dokumentacji do sfery ( ISparsowanyParametrRaportuWlasnego Interface ) są podane właściwości: ZakresDat_Koniec - Dotyczy parametru ZakresDat Określa datę końcową zakresu (jeżali taka jest wymagana) - literówka w opisie ZakresDat_Poczatek - Dotyczy parametru ZakresDat Określa datę początkową zakresu (jeżali taka jest wymagana) Oczywiście nie zadziałało. Na logikę doszedłem, że ma dwa parametry: Poczatek, Koniec. Ale jak go obsłużyć gdy TypZaresu ustawiony jest na 0 (Brak ograniczeń zakresu) i nie zwraca dat? .Where(dok => (data.TypZakresu != 0 && dok.DataWydaniaWystawienia >= (DateTime)data.Poczatek) && ( data.TypZakresu != 0 && dok.DataWydaniaWystawienia <= data.Koniec)) Problem 2 Wyłapałem, że parametr typu lista bazodanowa ma problem ze zwracaniem wszystkich wartości. Jako przykład podam oddziały podmiotu w bazie DEMO. Skonfigurowane są: CENTRALA, GALAXIA, OUTLET, a do parametru zwracane są tylko: GALAXIA i OUTLET. Problem 3 Próbuje w raporcie własnym odwzorować filtr typu dokumentu jak w raporcie Sprzedaż wg. dokumentu. Dodałem parametr typu wielokrotnego wyboru i pododawałem pozycje: 1 FS - Faktura sprzedaży 2 PA - Paragon 3 PI - Paragon imienny Chciałem to obsłużyć poniższym kodem, ale bez powodzenia: .Where(dok => WybranyTypDokumentu.Contains( dok.Symbol == "FS" ? 1 : dok.Symbol == "PA" ? 2 : dok.Symbol == "PI" ? 3 : 0)) Edit1: Problem 3 wynikał z zawieszenia się czegoś w Nexo. Po restarcie parametr zaczął działać poprawnie. Edit2: Problem 1 uzyskałem pomoc w innym miejscu i działający kod wygląda następująco: .Where(dok => (data.TypZakresu == 0 || dok.DataWydaniaWystawienia >= (DateTime?)data.Poczatek) && ( data.TypZakresu == 0 || dok.DataWydaniaWystawienia <= (DateTime?)data.Koniec))

Dla poniższego przypadku poproszę o wskazówkę jak odwołać się do innego repozytorium niż źródłowe. W raporcie jako source mamy wskazane KategoriaDokumentu. Chciałbym przed wywołaniem zapytania głównego odwołać się do Dokument i wykonać dodatkowe zapytanie sumujące wartości dla wszystkich dokumentów (na potrzeby dalszych obliczeń w zapytaniu głównym). null; // zapytanie dodatkowe, wartosc sprzedazy dla wszystkich dokumentow, koncepcja: // var suma = (from poz in Dokument select poz.WartoscTowarowNetto).Sum(); // zapytanie główne result = (from c in source // wartosc sprzedazy dla poszczegolnych kategorii let NettoSprzedaz = (from poz in c.Dokumenty select poz.WartoscTowarowNetto).Sum() select new Wynik { Id = c.Id, Nazwa = c.Nazwa, NettoSprzedaz = NettoSprzedaz, }) Kateogorie test - raport LINQ.xml

Zapiszę taką sugestię. O składnikach na liście umów już pisałem wyżej: "składniki to otwarty słownik więc ze względów wydajnościowych na razie nie planujemy tej sugestii realizować" Co do pozostałych sugestii - w programie nie ma gotowych tego typu zestawień - ale do generowania tak różnorodnych zapytań służą mechanizmy Raportów LINQ i Raportów SQL.

Na szybko: 1) tak, trzeba będzie (najpóźniej do wersji wiosennej) dostosować rozwiązania własne wykorzystujące zaawansowane pola własne 2) można pozostać przy starych polach własnych, najdłużej do wiosny 2020. W wiosennej wersji planujemy automatyczne przejście na nowe pola własne. W wersji 27 dajemy taką opcję. Pozwolę sobie skopiować część informacji o polach własnych z forum dla Partnerów InseRTu: Nowe zaawansowane pola własne W odpowiedzi na braki i problemy związane z funkcjonowaniem zaawansowanych pól własnych w obecnej postaci, podjęliśmy decyzję o stworzeniu nowego mechanizmu pól zaawansowanych. Ma on docelowo zastąpić mechanizm dotychczasowy. Nowe pola własne są niekompatybilne ze starymi i potrzebna będzie migracja danych. Proces migracji istniejących baz będzie bezproblemowy poza przypadkami, gdy w podmiocie są zaawansowane pola własne i dodatkowo używane są wykorzystujące je rozwiązania własne/partnerskie (rozwiązania sferyczne, raporty LINQ, raporty SQL czy wydruki własne). W takich przypadkach konieczne będzie dostosowanie tych rozwiązań do nowego mechanizmu. W związku z koniecznością zmian w rozwiązaniach własnych przewidujemy rozłożenie w czasie procesu migracji podmiotów klienckich. Zakładany harmonogram: - jesień 2019 – (wersja 27) – dodanie do nexo dostępnej dla wszystkich opcji przejścia na nowe pola własne, - wiosna 2020 – automatyczna migracja baz klienckich na nowy mechanizm. Powyższy harmonogram oznacza, że jest około roku czasu na to by dostosować rozwiązana własne i dostarczyć je klientom. Oczywiście zachęcamy do szybszego zmierzenia się z tym problemem, tym bardziej, że nowe pola własne to także nowe możliwości. Usprawnienia w nowej wersji zaawansowanych pól własnych: - Brak rekompilacji modelu danych po zmianach w zaawansowanych polach własnych - wymagane jest jedynie ponowne uruchomienie nexo, - Łatwiejsze tworzenie rozwiązań własnych ze względu na brak potrzeby kopiowania biblioteki InsERT.Moria.ModelDanych.dll po zmianach w zaawansowanych polach własnych, - Zaawansowanemu polu własnemu można przypisać dowolną ilość unikatowych aliasów nazwy. Aby pobrać lub ustawić wartość w polu można użyć jego nazwy lub jednego ze zdefiniowanych aliasów. Pozwala to na wykorzystanie tego samego pola w różnych rozwiązaniach własnych, gdy każde z rozwiązań odwołuje się do pola pod inną nazwą,[/list] - Wprowadzono słowniki własne SQL. W słownikach własnych SQL zbiór wartości pochodzi z wykonania zdefiniowanego zapytania SELECT, - Typ "kwota" został zastąpiony bardziej uniwersalnym typem "liczba rzeczywista", dla którego można określić ilość miejsc po przecinku, - Doszła możliwość określenia kolejności wyświetlania pól w oknie edycji pól własnych obiektu. Jak wypróbować nowe pola własne Aby przejść na nowe pola własne należy: - przejść do modułu laboratorium (Ctrl + Space + XX) i wybrać opcję "PRZEJDŹ NA POLA WŁASNE W WERSJI 2." Definiowanie w nexo pól własnych w nowej wersji: 1. W konfiguracji należy wybrać "System", a następnie wyszukać jeden z modułów: - "Pola własne" - po jego wybraniu wyświetlone zostają wszystkie obiekty, dla których można definiować pola własne - "Słowniki własne" - umożliwia wyświetlanie oraz dodanie/edycję/usunięcie słowników własnych i słowników własnych SQL 2. W konfiguracji zamiast "System" można także wybrać "Pola własne" Użycie pól własnych w wersji 2 w rozwiązaniach własnych 1. W SDK do nexo znajduje się przykład "nexoPolaWlasne2", który pokazuje m.in.: - W jaki sposób sprawdzić bieżącą wersję pól własnych (użycie interfejsu IWersjaPolWlasnych) - W jaki sposób odczytać informacje o zdefiniowanych zaawansowanych polach własnych wersji 2. oraz słownikach własnych wersji 2. (użycie interfejsu IZaawansowanePolaWlasne oraz ISlownikiWlasne) - W jaki sposób odczytać i ustawić wartości pól zaawansowanych wersji 2. w przykładowym obiekcie asortymentu - W jaki sposób używać pól własnych w wersji 2. w zapytaniach LINQ 2. Mechanizm prostych pól własnych nie uległ zmianie - nie jest wymagana modyfikacja rozwiązania własnego, które korzysta tylko z prostych pól własnych - nadal do pobrania informacji o prostych polach własnych można używać interfejsu IPolaWlasnePodstawowe - jednak tylko w zakresie dotyczącym prostych pól własnych (dla nowych rozszerzeń własnych zalecamy jednak używać nowego interfejsu IProstePolaWlasne) - sposób odczytu i ustawiania wartości prostych pól własnych nie uległ zmianie 3. Rozwiązania własne korzystające z zaawansowanych pól własnych muszą zostać dostosowane do współpracy z wersją 2. Po konwersji podmiotu do pól własnych wersji 2., rozwiązanie własne które korzysta z zaawansowanych pól własnych w wersji 1. przestanie działać poprawnie.

Poniższe informacje zostały pierwotnie opublikowane na Formu dla Parnterów. Pozwoliłem sobie je tu skopiować. W odpowiedzi na braki i problemy związane z funkcjonowaniem zaawansowanych pól własnych w obecnej postaci, podjęliśmy decyzję o stworzeniu nowego mechanizmu pól zaawansowanych. Ma on docelowo zastąpić mechanizm dotychczasowy. Nowe pola własne są niekompatybilne ze starymi i potrzebna będzie migracja danych. Proces migracji istniejących baz będzie bezproblemowy poza przypadkami, gdy w podmiocie są zaawansowane pola własne i dodatkowo używane są wykorzystujące je rozwiązania własne/partnerskie (rozwiązania sferyczne, raporty LINQ, raporty SQL czy wydruki własne). W takich przypadkach konieczne będzie dostosowanie tych rozwiązań do nowego mechanizmu. W związku z koniecznością zmian w rozwiązaniach własnych przewidujemy rozłożenie w czasie procesu migracji podmiotów klienckich. Zakładany harmonogram: - jesień 2019 – (wersja 27) – dodanie do nexo w laboratorium dostępnej opcji przejścia na nowe pola własne, - wiosna 2020 (wersja 30) staną się następujące rzeczy: podmioty utworzone w wersji 30 lub wyższej będą od razu działały z włączonymi polami zaawansowanymi v2 podmioty konwertowane z wersji wcześniejszej do wersji 30, które nie posiadają żadnych pól zaawansowanych, od wersji 30 będą działały z włączonymi polami v2 podmioty konwertowane z wersji wcześniejszej do wersji 30, które posiadają pola zaawansowane, pozostaną w trybie pól v1, przy czym: przycisk przejścia na pola v2 stanie się ogólnie dostępny dla wszystkich użytkowników użytkownicy będą zachęcani do przejścia na pola v2 (m.in. z sugestią wcześniejszego skontaktowania się z Partnerem/Serwisantem) powyższe oznacza, że użytkownicy z zaawansowanymi polami własnymi będą mogli odroczyć migrację na pola własne v2 do wersji 31 (czerwiec/lipiec 2020), kiedy to nastąpi automatyczna migracja Usprawnienia w nowej wersji zaawansowanych pól własnych: brak rekompilacji modelu danych po zmianach w zaawansowanych polach własnych, przyspieszony restart aplikacji po zmianach w zaawansowanych polach własnych, usunięcie błędów i problemów w działaniu, w tym także związanych z aktualizacją do nowej wersji nexo, możliwość tworzenia słowników własnych SQL. w których zbiór wartości pochodzi z wykonania zdefiniowanego zapytania SELECT, możliwość wybrania wartości domyślnej dla pola słownikowego, zastąpienie typu "kwota" bardziej uniwersalnym typem "liczba rzeczywista", dla którego można określić ilość miejsc po przecinku, możliwość określenia, oprócz wymagalności i widoczności, także tego czy pole zaawansowane ma być edytowalne oraz klonowalne, możliwość określenia kolejności wyświetlania pól zaawasnowanych w oknie edycji pól własnych obiektu, zaawansowanemu polu własnemu można przypisać dowolną ilość unikatowych aliasów nazwy. Aby pobrać lub ustawić wartość w polu można użyć jego nazwy lub jednego ze zdefiniowanych aliasów. Pozwala to na wykorzystanie tego samego pola w różnych rozwiązaniach własnych, gdy każde z rozwiązań odwołuje się do pola pod inną nazwą,[/list] Jak wypróbować nowe pola własne w wersji wcześniejszej niż 30 Aby przejść na nowe pola własne należy wejść do modułu laboratorium (Ctrl + Space + XX) i wybrać opcję "PRZEJDŹ NA POLA WŁASNE W WERSJI 2." W celu definiowania pól własnych oraz słowników w nowej wersji: 1. W konfiguracji należy wybrać "System", a następnie wyszukać jeden z modułów: - "Pola własne" - po jego wybraniu wyświetlone zostają wszystkie obiekty, dla których można definiować pola własne - "Słowniki własne" - umożliwia wyświetlanie oraz dodanie/edycję/usunięcie słowników własnych i słowników własnych SQL 2. W konfiguracji zamiast "System" można także wybrać "Pola własne" Użycie pól własnych w wersji 2 w rozwiązaniach własnych 1. W dokumentacji do sfery InsERT.nexo.Sfera.chm (gałąź "Rozszerzanie/Pola własne") znajdują się informacje: - W jaki sposób sprawdzić bieżącą wersję pól własnych - W jaki sposób odczytać informacje o zdefiniowanych zaawansowanych polach własnych wersji 2. oraz słownikach własnych wersji 2. - W jaki sposób odczytać i ustawić wartości pól zaawansowanych wersji 2. - W jaki sposób używać pól własnych w wersji 2. w zapytaniach LINQ 2. Mechanizm prostych pól własnych nie uległ zmianie - nie jest wymagana modyfikacja rozwiązania własnego, które korzysta tylko z prostych pól własnych 3. Rozwiązania własne korzystające z zaawansowanych pól własnych muszą zostać dostosowane do współpracy z wersją 2. Po konwersji podmiotu do pól własnych wersji 2., rozwiązanie własne które korzysta z zaawansowanych pól własnych w wersji 1. przestanie działać poprawnie. Użycie pól własnych w wersji 2 na wydrukach Proszę zajrzeć do osobnego tematu: Struktura pól własnych v2 w bazie danych Proszę zajrzeć do osobnego tematu: