Podczas tworzenia raportów w systemie kontroli dostępu często zachodzi potrzeba wyświetlenia na formularzu raportu wyboru okresu, dzięki czemu nie trzeba ręcznie wpisywać dat, tylko wybrać z listy standardowych okresów, np.: „Rok” , „Miesiąc”, „Tydzień” itp. . Dla parametrów typu Data można określić tylko „Początek tego roku, miesiąca itp.”, ale nie jest podany „Koniec”.
Rzecz w tym, że z typów danych dostępny jest tylko typ „Standardowa data początkowa”, ale chcę też „Standardową datę końcową”.
Istnieje sposób, aby to obejść.
Ale jest pewna subtelność. Jeśli w zapytaniu użyjemy tabel wirtualnych, najprawdopodobniej raport przestanie działać i wyświetli się komunikat o błędzie typu „Błąd przetwarzania widoku, niezgodność typu, numer parametru...”.
Aby tego uniknąć, należy usunąć wszystkie parametry tabeli wirtualnej.
I dodaj je do tabel w zakładce „Skład danych”.
Aby parametry wyświetlały się w ustawieniach szybkiego raportu, włączmy odpowiednią flagę dla parametrów raportu.
Teraz wybór okresu w formularzu raportu wygląda następująco.
W tym artykule omówiono niektóre funkcje konfigurowania okresu podczas korzystania z systemu składu danych (DCS), problemy pojawiające się w wyniku różnic w koncepcji okresu między zwykłym użytkownikiem a systemem 1C, a także sugeruje sposoby ich rozwiązania .
Większość raportów tworzonych przy użyciu Systemu Składu Danych (DCS) wymaga od użytkownika podania okresu, za który raport będzie tworzony. Z reguły w ACS wprowadzanie okresów jest zorganizowane poprzez parametry, stosując następującą konstrukcję, patrz. Ryc.1 Ta metoda wejścia w okres jest uważana za „klasyczną”; została opisana w artykule na temat ITS i innej literaturze poświęconej rozwojowi w 1C, więc przyjmijmy ją jako podstawę. Rozważmy jako przykład proste żądanie, w ramach którego otrzymane zostaną wszystkie dokumenty Sprzedaż towarów i usług za dany okres, patrz Ryc.2 Korzystając z tego raportu, użytkownik ustawia okres za pomocą parametrów, patrz. Ryc.3 Wszystko wydaje się być w porządku... ALE jest mały problem:
Rzecz w tym, że zdecydowana większość użytkowników „rozumie” ten okres inaczej niż 1C „rozumie” go, przykłady:
1). Rozważmy Ryc.3
Z punktu widzenia użytkownika okres nie jest określony, czyli NIEOGRANICZONY, czyli w raporcie powinny zostać uwzględnione WSZYSTKIE dokumenty bez ograniczeń datowych.
„Z punktu widzenia” systemu 1C parametr okresu jest ustawiony i… obie jego granice są równe 01.01.0001 i w raporcie zostaną uwzględnione tylko dokumenty z pustą datą, co w praktyce oznacza nie dołączony zostanie pojedynczy dokument.
2). Rozważmy Ryc.4
Z punktu widzenia użytkownika raport powinien zawierać wszystkie dokumenty począwszy od daty 28.01.2010.
„Z punktu widzenia” 1C okres 28.01.2010 - 01.01.0001 spowoduje wyjątek.
Możesz oczywiście spróbować wyjaśnić użytkownikowi, dlaczego raport nie wyświetla dokumentów, które spodziewa się zobaczyć i jak przedstawiany jest okres z „punktu widzenia” 1C, ale jest to niewdzięczne zadanie i to jest również błędne. Dobry program powinien przede wszystkim być przyjazny dla użytkownika, ponieważ program istnieje dla użytkownika, a nie odwrotnie, dlatego będziesz musiał „nauczyć” 1C, aby rozumieć okres tak, jak rozumie go użytkownik, a mianowicie:
1). Początek okresu i koniec okresu nie są określone -> wszystkie dokumenty.
2). Określony jest tylko początek okresu –> wszystkie dokumenty rozpoczynające się od początku okresu
3). Dodatkowo sprawdzimy, czy Koniec Okresu >= Początek Okresu, a jeśli nie jest to prawdą, to przyjmiemy, że Koniec Okresu nie jest określony, tj. 2).
W związku z powyższym wyrażenie parametru Data końcowa będzie wyglądać następująco:
WYBIERZ KIEDY &Period.EndDate=DATACZAS(1,1,1) NASTĘPNIE DATACZAS(3999,12,31,23,59,59) W przeciwnym razie WYBIERZ KIEDY &Period.EndDate<&Период.ДатаНачала ТОГДА ДАТАВРЕМЯ(3999,12,31,23,59,59) ИНАЧЕ &Период.ДатаОкончания КОНЕЦ КОНЕЦ
Ostateczną formę naszego projektu wyboru okresu pokazano w Ryc.5
Niektóre możliwości ustawienia okresu w systemie kontroli dostępu.
Większość raportów tworzonych przy użyciu Systemu Składu Danych (DCS) wymaga od użytkownika podania okresu, za który raport będzie tworzony.
Z reguły w ACS wprowadzanie okresu jest zorganizowane poprzez parametry, stosując następującą konstrukcję, patrz. Ta metoda wprowadzania okresu jest uważana za „klasyczną” i jest opisana w artykule na temat ITS i innej literaturze poświęconej rozwojowi w 1C, tzw przyjmijmy to jako podstawę. Rozważmy jako przykład proste żądanie, w ramach którego otrzymane zostaną wszystkie dokumenty Sprzedaż towarów i usług za dany okres, patrz
Korzystając z tego raportu, użytkownik ustawia okres poprzez parametry, patrz. Wszystko wydaje się być prawidłowe..., ALE jest mały problem:
Rzecz w tym, że zdecydowana większość użytkowników „rozumie” ten okres inaczej niż 1C „rozumie” go, przykłady:
Z punktu widzenia użytkownika okres nie jest określony, czyli NIEOGRANICZONY, czyli w raporcie powinny zostać uwzględnione WSZYSTKIE dokumenty bez ograniczeń datowych.
„Z punktu widzenia” systemu 1C parametr okresu jest ustawiony i… obie jego granice są równe 01.01.0001 i w raporcie zostaną uwzględnione tylko dokumenty z pustą datą, co w praktyce oznacza nie dołączony zostanie pojedynczy dokument.
Z punktu widzenia użytkownika raport powinien zawierać wszystkie dokumenty począwszy od daty 28.01.2010.
„Z punktu widzenia” 1C okres 28.01.2010 - 01.01.0001 spowoduje wyjątek.
Możesz oczywiście spróbować wyjaśnić użytkownikowi, dlaczego raport nie wyświetla dokumentów, które spodziewa się zobaczyć i jak przedstawiany jest okres z „punktu widzenia” 1C, ale jest to niewdzięczne zadanie i to jest również błędne. Dobry program powinien przede wszystkim być przyjazny dla użytkownika, ponieważ program istnieje dla użytkownika, a nie odwrotnie, dlatego będziesz musiał „nauczyć” 1C, aby rozumieć okres tak, jak rozumie go użytkownik, a mianowicie:
1). Początek okresu i koniec okresu nie są określone -> wszystkie dokumenty.
2). Określony jest tylko początek okresu -> wszystkie dokumenty rozpoczynające się od początku okresu
3). Dodatkowo sprawdzimy, czy Koniec Okresu >= Początek Okresu, a jeśli nie jest to prawdą, to przyjmiemy, że Koniec Okresu nie jest określony, tj. 2).
W związku z powyższym wyrażenie parametru Data końcowa wygląda następująco:
KIEDY &Period.EndDate=DATACZAS(1,1,1)
NASTĘPNIE DATACZAS(3999,12,31)
KIEDY &Data zakończenia okresu<&Период.ДатаНачала
NASTĘPNIE DATACZAS(3999,12,31) DATACZAS(3999,12,31,23,59,59)
Data zakończenia &okresu
Ostateczną formę naszego projektu wyboru okresu pokazano w
Uwaga: ten mechanizm ustawiania parametrów jest przeznaczony dla starszych platform 1C 8.1 i 8.2 (oraz konfiguracji działających pod ich kontrolą); starsze wersje platformy 1C mają wbudowane mechanizmy kontrolowania pustych parametrów i nie ma potrzeby uciekania się do mechanizmu dodatkowo opisano w tym artykule. W niektórych wersjach platformy 1C możliwe są błędy i nieprawidłowe działanie.
Zacznijmy więc.
Dla uproszczenia zrozumienia przykładu zbudujemy jeden prosty krążący rejestr akumulacji.
W moim przypadku jest to rejestr akumulacji „Rachunkowość pracy w toku”.
Przykładowo będziemy wskazywać jego parametry na sztywno (a nie poprzez miękkie narzucanie parametrów na system kontroli dostępu):
Należy pamiętać, że częstotliwość wirtualnego stołu to „Nagraj”.
Ale jak wspomniano powyżej, potrzebujemy okresu pod względem okresowości, dlatego proponuję obliczyć pole „Okres” w następujący sposób (niezbyt ładnie, ale nie widziałem lepszych opcji):
Jak widać na zrzucie ekranu do żądania przekazywany jest parametr, który użytkownik określa w formularzu: Wartość wyliczenia „Częstotliwość” – wyliczenie to występuje niemal we wszystkich standardowych rozwiązaniach.
W zakładce „Parametry” wskażemy jego dostępne typy:
Dzięki temu ustawieniu formatujemy nasz okres tak, aby wszystko było piękne i miłe dla oka)
Oto same formaty:
Miesiąc: DF="MMMM rrrr "y.""
Dzień: DF = dd.MM.rrrr
Tydzień: DF = ""Tydzień od "dd.MM.rrrr"
Kwartał: DF = „do „ćwiartki” rrrr „y.”
Rok: DF = „yyyy „y.”
Dekada: DF = ""Dekada od "dd.MM.rrrr"
Pół roku: DF = „„Pół roku od” dd.MM.rrrr”
To wszystko. Rezultatem jest wspaniały obraz:
Utwórzmy raport z jednym zestawem danych zapytania:
WYBIERZ PRODUKTY W MAGAZYNACH Pozostało. Magazyn, towary w magazynach pozostają. Nomenklatura, produkty pozostałe w magazynach. Saldo ilościowe Z Rejestru Akumulacji. ProduktyW Magazynach. Pozostałości(&MojaData ,) AS ProductsInWarehousesRemainsPrzejdźmy teraz do zakładki parametry i zobaczmy, że system oprócz naszego parametru &MyDate utworzył także parametr &Period.
W celu wizualnego monitorowania okresów utworzymy główny formularz raportu i umieścimy w nim pole tabeli z danymi: Settings Composer.Settings.DataParameters 
Zapiszmy raport i otwórzmy go w przedsiębiorstwie. W polu tabeli z parametrami wyświetlany jest wyłącznie parametr &Period:
W związku z tym jakakolwiek zmiana tego parametru nie przyniesie pożądanego rezultatu.
Dlaczego parametr &MyDate jest niedostępny? Oczywiście, bo na zakładce parametrów ma zaznaczone checkboxy Ograniczenie dostępności.
Odznacz to pole. Teraz widzimy oba w dostępnych parametrach. Dopiero podczas generowania raportu zobaczymy, że raport reaguje na parametr &Period, a nie na &MyDate.
W tym przykładzie najprościej jest zmienić nazwę parametru &MyDate w żądaniu na &Period i osiągnąć pożądany rezultat. Ale może masz zapytanie, w którym użyto już parametru &Period, lub Twoje poglądy religijne nie pozwalają na użycie tego parametru, w każdym razie możesz rozwiązać problem w ten sposób:
WYBIERZ PRODUKTY W MAGAZYNACH Pozostało. Magazyn, towary w magazynach pozostają. Nomenklatura, produkty pozostałe w magazynach. Saldo ilościowe Z Rejestru Akumulacji. ProduktyW Magazynach. Remains((&MyDate) ,) AS ProductsInWarehousesRemainsUPD od użytkownika Gwizd:
Głównym problemem przy stosowaniu parametrów „standardowych” (dodawanych przez system) jest to, że w przypadku korzystania z kilku tabel wirtualnych w raporcie, jeśli ten parametr zostanie zdefiniowany, we wszystkich pozostałych przypadkach zostanie użyta jego wartość, a nie „własnych”.
Podam przykład:
WYBIERZ pracownikówSP.Employee, WorkersSP.ReasonChangesState, WorkersSP.Period, WorkersSPAnotherDate.Period AS Period2, WorkersSPAnotherDate.ReasonChangesStates AS ReasonChangesState2 Z RegisterInformation.EmployeesOrganizations.SliceLast(&Period , Employee = &Employee ) AS Work nikkiSP POŁĄCZENIE LEWE Rejestr informacji.Pracownicy organizacji.Wycinek ostatniej (&OtherDate ,) AS EmployeesSPAnotherDate BY EmployeesSP.Employee = EmployeesSPAnotherDate.EmployeeW drugim podzapytaniu jako parametr daty wycinka zostanie użyta wartość „standardowego” parametru PERIOD, a nie wartość OtherDate.
Ta „usterka” zostanie zaobserwowana nawet wtedy, gdy drugie podzapytanie zostanie przesłane do drugiego zestawu danych i połączone za pomocą ACS. Opcja użycia wyrażenia typu „ADDATA(&kropka, MIESIĄC, -1)” w drugim żądaniu również nie będzie działać, miesiąc nie zostanie odjęty. Jednak zmiana nazwy parametru „Period” w żądaniu na przykład na „FirstDate” rozwiązuje ten problem.
Nawiasem mówiąc, dokładnie ten sam problem obserwuje się w przypadku wirtualnych tablic akumulacyjnych i rejestrów księgowych, służących do uzyskiwania na przykład obrotów. Tam system dodaje parametry „Początek okresu” i „Koniec okresu”.
Zatem w przypadku wniosków o nawet nieco większym stopniu skomplikowania sensowne jest wyłączenie dostępności i stosowanie „okresów standardowych”.
