Procedura pracy z wbudowanym obiektem żądania języka. Jaki jest cel obiektu konfiguracyjnego „Język”?
Opracowanie rozwiązania aplikacyjnego w systemie 1C: Enterprise składa się z dwóch głównych działań: wizualnego projektu obiektów konfiguracyjnych oraz opisu konkretnego zachowania systemu za pomocą wbudowanego języka i języka zapytań.
Wbudowany język systemu 1C: Enterprise ma wiele podobieństw z innymi językami programowania, ale nie jest bezpośrednim analogiem żadnego z nich. Jego najważniejsze cechy:
· miękkie typowanie (typ zmiennej zależy od rodzaju zawartej w niej wartości i może zmieniać się w trakcie operacji);
· brak opisów programowych typów aplikacji (powstają one podczas dodawania obiektów konfiguracyjnych);
· Wbudowany język zorientowany na zdarzenia;
· wszyscy operatorzy mają pisownię rosyjską i angielską, których można używać jednocześnie.
Moduły konfiguracyjne
Moduły rozwiązania aplikacyjnego przeznaczone są do umieszczenia tekstu programu we wbudowanym języku. Moduły te znajdują się w różnych miejscach konfiguracji i mają różne przeznaczenie. Większość modułów jest „powiązana” z określonymi obiektami konfiguracyjnymi lub z samym rozwiązaniem aplikacyjnym.
Wyróżnia się następujące typy modułów oprogramowania:
· Wspólne moduły. Konfiguracja może mieć dowolną liczbę modułów, w tym żadnego. Same moduły wspólne nie są wywoływane podczas procesu konfiguracji. Służą jedynie do przechowywania tekstów procedur i funkcji, które można wywołać z innych modułów rozwiązania aplikacyjnego. Dlatego brakuje im sekcji opisu zmiennych i sekcji programu głównego. To. Wspólne moduły zawierają tylko procedury i funkcje.
· Moduł aplikacji. W konfiguracji zawsze występuje jeden moduł aplikacji. Jest wykonywany, gdy system uruchamia się w trybie 1C: Enterprise i ma na celu opracowanie działań związanych z sesją roboczą użytkownika końcowego. Głównymi zdarzeniami, które mogą być przetwarzane w module aplikacji, są zdarzenia początkowe i końcowe aplikacji. Sekwencja połączenia jest pokazana w Ryż. 1. Wydarzenie Przed uruchomieniem systemu Występuje, gdy system zostanie uruchomiony przed otwarciem okna głównego. Obsługując to zdarzenie, programista ma na przykład możliwość odmowy uruchomienia, jeśli nie zostaną spełnione jakiekolwiek warunki. Wydarzenie Podczas uruchamiania systemu następuje po otwarciu okna głównego. W procedurze obsługi tego zdarzenia możesz np. wyświetlić informację o osobach obchodzących urodziny itp.
· Zewnętrzny moduł przyłączeniowy. W konfiguracji zawsze występuje jeden zewnętrzny moduł przyłączeniowy. Jest wykonywany, gdy dostęp do aplikacji odbywa się jako serwer COM (w trybie połączenia zewnętrznego). W trybie połączenia zewnętrznego uruchamiana jest nie pełnoprawna aplikacja 1C: Enterprise, ale „wersja lekka”, w której nie są dostępne wszystkie funkcje, które są w ten czy inny sposób związane z organizacją interfejsu użytkownika.
· Moduły obiektu aplikacji. Każdy obiekt konfiguracji aplikacji (na przykład dokument oprogramowania lub katalog), którego dane można modyfikować w trybie 1C: Enterprise, ma swój własny moduł. Oprócz opisu zmiennych i programu głównego, moduł obiektowy może zawierać opis procedur – procedur obsługi zdarzeń powiązanych z danym obiektem konfiguracyjnym. Istnieją dwa zdarzenia wywoływane dla wszystkich obiektów — Przed nagraniem I Kiedy nagrywanie.
· Moduły formularzy. Każdy formularz posiada swój moduł, który określa zachowanie formularza i wykonywane na nim akcje, np. otwieranie innych formularzy. Zdarzenia są wywoływane dla wszystkich formularzy Przed otwarciem, w trakcie otwierania, przed zamknięciem I Przy zamknięciu.
Kontekst
W systemie 1C: Enterprise kontekst oznacza środowisko modułu, tj. dostępnych dla niego zmiennych, obiektów, właściwości, metod i zdarzeń. Wyróżniamy następujące typy kontekstów, a co za tym idzie zasady widoczności eksportowanych zmiennych, procedur i funkcji:
· Kontekst globalny, dostępny we wszystkich innych kontekstach, składa się z następujących części:
§ właściwości, metody i zdarzenia kontekstu globalnego (na przykład właściwość Data robocza);
§ wyliczenia systemowe i zestawy wartości systemowych (na przykład Zwróć okno dialogowe kodu I Symbolika).
· Wspólny kontekst modułu utworzony przez kontekst globalny i kontekst lokalny samego modułu ogólnego (tj. procedury i funkcje zdefiniowane w module ogólnym). W kontekście wspólnego modułu dostępne są wyeksportowane procedury i funkcje innych wspólnych modułów. Wyeksportowane zmienne, procedury i funkcje modułu aplikacji nie są dostępne.
· W kontekście modułu aplikacji lub modułu połączeń zewnętrznych Dostępne są wyeksportowane procedury i funkcje wspólnych modułów.
· W kontekście modułu obiektu aplikacji istnieje dostęp do szczegółów i części tabelarycznych obiektu, a także jego metod i zdarzeń. Tutaj dostępne są wyeksportowane zmienne, procedury i funkcje modułu aplikacji (modułu połączeń zewnętrznych) oraz modułów wspólnych.
· W kontekście modułu formularza dostępne są szczegóły formularza, a także właściwości, metody i zdarzenia formularza. Jeżeli do formularza przypisany jest atrybut główny, to w module formularza dostępne są właściwości i metody obiektu aplikacji użytego jako atrybut główny.
Schematycznie pokazane są zależności pomiędzy kontekstami Ryż. 2. NA Ryż. 3 przedstawia możliwą interakcję modułu formularza dziennika i modułu dokumentu.
Procedury i funkcje
Procedury i funkcje to bloki programu, które można wywołać po nazwie z innego miejsca, na przykład z innej procedury. Funkcje różnią się od procedur tylko tym, że mają wartość zwracaną. W wersji 8 kolejność procedur i funkcji nie jest istotna. Oznacza to, że procedura może znajdować się poniżej miejsca, w którym jest wywoływana.
Procedury i funkcje mogą mieć parametry określające, jakie działania powinny wykonywać na jakich obiektach. Parametry procedury lub funkcji są domyślnie przekazywane przez referencję. Oznacza to, że zmiana formalnego parametru w procedurze lub funkcji spowoduje zmianę rzeczywistego parametru w momencie jego wywołania. Aby mieć pewność, że parametr zostanie przekazany przez wartość, przed nazwą parametru należy wstawić słowo kluczowe Oznaczający.
Przykład 1:
Procedura Oblicz()
Kwota=cena*ilość;
Koniec procedury
Obliczenie(); // Wywołaj procedurę
Przykład 2:
Perem Glob;
// Opis procedury
Eksport obliczeń procedury (Par1, Par2, ParZ).
Glob = Glob + Par1 + Par2 + ParZ;
Koniec procedury
Obliczenia(5, 6, 7); // Wywołaj procedurę
Przykład 3:
Perem Glob;
// Opis funkcji
Eksport obliczeń funkcji (Par1, Par2, ParZ).
Lok = Glob + Par1 + Par2 + ParZ;
Blokada powrotu;
Funkcja końcowa
Res = Oblicz(5, 6, 7); // Wywołanie funkcji
Typy danych
Liczba, Łańcuch, Data, Boolean, Niezdefiniowane, Null (dla nieokreślonych wartości w tabelach bazy danych)
Typ. Do reprezentowania i porównywania typów danych potrzebne są wartości specjalnego typu „Typ”, na przykład:
Deklarowanie zmiennych
Zmienne pojawiają się w programie w następujących przypadkach:
· po ich zadeklarowaniu za pomocą operatora Zmienna.
Perem<Имя_переменной>[Eksport];
Zmienna A, B;
· po pierwszym umieszczeniu nazwy zmiennej po lewej stronie operatora przypisania.
Przykład:
· przy ustalaniu nazw identyfikatorów edytowanych elementów okna dialogowego;
· przy ustalaniu parametrów formalnych procedur.
Rzucać
Rzutowanie typu może być jawne lub ukryte.
Do jawnego rzutowania istnieją następujące funkcje: Number, String, Date, Boolean. Niejawne rzutowanie typu jest wykonywane automatycznie przez system podczas oceny wyrażeń.
Przykład: Wartość zmiennej numerycznej MonthNumber jest niejawnie konwertowana na ciąg znaków i dołączana do innego ciągu:
A = „Miesiąc” + Numer miesiąca;
Katalogi
Praca z katalogami odbywa się za pomocą następujących obiektów:
· Menedżer katalogów. Zapewnia dostęp do wszystkich podręczników konfiguracji. Właściwości tego obiektu pokrywają się z nazwami katalogów i zawierają obiekty typu DirectoryManager.
· Menedżer katalogów. Zapewnia dostęp do operacji na katalogu jako zestawie elementów. Za pomocą metod tego obiektu można wyszukiwać, uzyskiwać wybór, tworzyć nowe elementy oraz uzyskiwać dostęp do formularzy i układów katalogów.
· KatalogLink. Jednoznacznie identyfikuje element (grupę) katalogu i umożliwia dostęp do niego w trybie tylko do odczytu. Dzięki właściwościom i metodom tego obiektu można odczytać szczegóły elementu (grupy) i uzyskać dostęp do jego części tabelarycznych. Wartość tego typu przechowywana jest w atrybutach odnoszących się do elementów tego katalogu, np. w atrybucie Pracownik dokument Rekrutacja przechowywane jest łącze do określonego elementu katalogu Pracownicy.
· Obiekt katalogu. Zapewnia dostęp do elementu z możliwością zapisu. Obiekt ten zawiera metody, które wpływają na element w bazie danych, na przykład metody Zanotować I Usuwać.
· Wybór katalogu. Zapewnia możliwość iteracji po elementach katalogu. Próbkowanie może być bezpośrednie lub hierarchiczne.
· Lista katalogów. Obiekt służący do zarządzania listą elementów w polu tabeli. Umożliwia zarządzanie kolumnami, zaznaczaniem i sortowaniem na liście.
W systemie 1C:Enterprise?
1. Teksty konfiguracyjne i bazy danych zapisywane są w formacieUNIKOD
3. Nie ma właściwej odpowiedzi
6.75 W jakim celu przechowywane są w formacie teksty konfiguracyjne i bazy danychUNIKOD?
1. Format UNICODE zapewnia niezmienność (niezależność od platformy oprogramowania systemu operacyjnego) prezentacji informacji
2. FormatUNIKOD pozwala na obsługę różnych języków w systemie 1C:Enterprise
3. Nie ma właściwej odpowiedzi
6.76 Określone mechanizmy internacjonalizacji. ..
1. platforma technologiczna 1C:Enterprise
2. zastosowane rozwiązania
3. Odpowiedzi 1 i 2 są poprawne
4. nie ma właściwej odpowiedzi
6.77 Co to jest kod lokalizacyjny?
1. Ciąg składający się z kodu języka i kodu kraju, który identyfikuje jakiś region świata
2. Kod produktu oprogramowania (wskazany w formularzu rejestracyjnym, dokumentacja dołączona do zestawu)
3. Opcja formatowania ciągu do konwersji
4. Jej odpowiedź jest prawidłowa
6.78 Czy to prawda, że w 1C:Enterprise 8 każda informacja tekstowa może jednocześnie zawierać znaki z różnych języków?
1. Tak, ponieważ wszystkie teksty konfiguracyjne i bazy danych są zapisywane w formacieUNIKOD
2. W zależności od ustawień określonych podczas tworzenia bazy danych
3. Tylko jeśli pozwala na to konfiguracja
6.79 Jaki jest cel obiektu konfiguracyjnego „Język”?
1. Aby utworzyć interfejs programu w różnych językach
2. Tworzenie dokumentów tekstowych w różnych językach
3. Taki obiekt nie istnieje w 1C: Enterprise 8
6.80 Jak zmienić język przeglądania (edycji) konfiguracji?
1. Za pomocą przycisku wyboru języka znajdującego się na pasku stanu po prawej stronie przycisku „NUM”.
2. Poprzez punkt menu „Konfiguracja – Język edycji konfiguracji”
3. W 1 C: Enterprise taka możliwość nie istnieje
4. Verpa odpowiada na pytania 1 i 2
6.81 Jaka jest pisownia wbudowanych operatorów językowych?
1. Tylko pismo rosyjskie
3.
6.82 Czy możliwe jest użycie wbudowanych operatorów językowych w piśmie rosyjskim i angielskim w jednym tekście źródłowym?
1. Tylko przy specjalnych ustawieniach konfiguratora
2. Tak, nie wymaga to zmiany jakichkolwiek ustawień konfiguratora
3. Nie, ponieważ opcja wbudowanego języka jest ustawiona we właściwościach konfiguracyjnych
6.83 Jaki jest cel języka wbudowanego?
1. Aby określić domyślny interfejs programu
2. Opisać (na etapie opracowywania konfiguracji) algorytmy działania zastosowanego zadania
3. Nie ma właściwej odpowiedzi
6.84 Jaka jest pisownia wbudowanych funkcji językowych?
1. Tylko pismo rosyjskie
2. Tylko pisownia angielska
3. Pismo rosyjskie i angielskie
4. W zależności od ustawień konfiguratora
6.85 Co oznacza parametr L?(L) w ciągu formatującym funkcji formatującej NumberInWriting()?
1. Znak „wypisz część ułamkową w liczbach/słowach”
2. Liczba miejsc po przecinku
3. Kod lokalizacyjny
7. Tabelaryczny model rozwiązania aplikacyjnego
7.1 Konfigurując ograniczenia dostępu do danych, możesz ustawić kilka (w zależności od liczby pól) ograniczeń:
1. Dla prawa „Czytaj”.
2. Dla właściwej „Zmiany”
3. Dla prawa „Dodaj”.
4. Dla prawa „Usuń”.
5. Dla wszystkich powyższych praw
6. O wszelkie możliwe prawa
7.2 Konfigurując ograniczenia dostępu do danych, jako wartości, według których tworzone są ograniczenia dostępu do danych, można zastosować następujące wartości:
1. Tylko wartości parametrów sesji
2. Tylko dane z tabel (zapytań)
3. Wartości parametrów sesji i dane z tabel (zapytań)
4. Tylko wartości z typami: Number, String, Boolean, Date
7.3 Której z powyższych metod można użyć, aby kod i nazwa katalogu pojawiły się w sekcji „Pola” projektanta zapytań?
1. Najpierw wypełnij sekcję „Tabele”, a następnie wybierając żądane obiekty z tej sekcji, przesuń je do sekcji „Pola” za pomocą podwójnego kliknięcia lewym przyciskiem myszy
2. Bez wypełniania sekcji „Tabele” od razu wybierz niezbędne obiekty z tabel - źródeł danych sekcji „Baza danych”, przenosząc je do sekcji „Pola” za pomocą technologii Drag & Drop. Sekcja „Tabele” jest wypełniana automatycznie
3. Najpierw wypełnij sekcję „Tabele”, a następnie wybierając niezbędne obiekty z tej sekcji przenieś je do sekcji „Pola” za pomocą przycisków znajdujących się na formularzu „>” „””
4. Odpowiedzi I i 3 są prawidłowe
5. Odpowiedzi I, 2 i 3 są prawidłowe
7.4 Aby zwiększyć szybkość realizacji żądania, należy:
1. Ustaw parametry dla większości rzeczywistych tabel
2. Ustaw parametry dla większości tabel wirtualnych
3. Zamiast podawać parametry tabeli rzeczywistej lub wirtualnej, skorzystaj z selekcji określonej konstrukcją języka zapytań „WHERE”
4. Odpowiedzi I i 2 są prawidłowe
7.5 Czy można nadać jej nową nazwę (alias) podczas wybierania tabeli źródłowej w sekcji „Tabele” projektanta zapytań?
1. tak, możesz
2. Tak, ale tylko wtedy, gdy źródłem danych jest zapytanie zagnieżdżone
3. Tak, ale tylko wtedy, gdy źródłem danych jest tabela wirtualna
4. Odpowiedzi 1 i 2 są poprawne
5. Odpowiedzi 1 i 3 są poprawne
7.6 Można zastosować zapytanie zagnieżdżone:
1. Jako tabela źródła danych
2. Jako argument operacji porównania „B” lub „NOT B” przy ustawianiu parametrów tabeli wirtualnej
3. Jako argument operacji porównania „B” lub „NOT B” przy określaniu konstrukcji języka zapytań „WHERE”
4. Verpa odpowiada na pytania 1, 2 i 3
7.7 Czy przy użyciu projektanta zapytań można uzyskać sumy według hierarchii?
1. Jest to możliwe, jeśli w polu grupowania określisz całkowity typ „Elementy i hierarchia”.
2. Jest to możliwe, jeśli w polu grupowania określisz typ całkowity „Tylko hierarchia”.
3. Verpa odpowiada na pytania 1 i 2
7.8 W zakładce „Warunki” projektanta zapytań można wygenerować osobną linię listy warunków:
1. Kliknij dwukrotnie lewym przyciskiem myszy żądane pole na liście dostępnych pól
2. Przenosząc wybrane pole na listę za pomocą technologii Drag & Drop
3. Kliknij przycisk „Dodaj”. Jeżeli warunek jest dowolny, wówczas tekst warunku można wprowadzić „ręcznie”
4. Wywołaj menu kontekstowe i wybierz z niego „Dodaj”. Możliwe jest użycie dowolnego wyrażenia
5. Wszystkie powyższe odpowiedzi są prawidłowe
7.9 W zakładce „Linki” projektanta zapytań możesz zdefiniować:
1. Łączenie tabel źródła danych i relacji między nimi
2. Łączenie tabel źródeł danych i połączeń między nimi
3. Relacje pomiędzy polami tabeli uzyskane w wyniku zapytania
4. Zależności pomiędzy polami tabeli źródła danych a tabelą uzyskaną w wyniku zapytania
7.10 Łącząc tabele źródła danych w projektancie zapytań, możesz:
1. Przypisz połączenie bez określania warunku połączenia
2. Przypisz połączenie wskazując warunek połączenia, a warunek ten może być tylko jeden
3. Przypisz połączenie wskazując warunek połączenia, a warunek ten może być tylko prosty
4. Przypisz wymaganą liczbę połączeń, wskazując wymaganą liczbę warunków komunikacji, a warunki te mogą być proste lub dowolne
7.11 Utworzenie połączenia pomiędzy tabelami źródeł danych w projektancie zapytań umożliwia:
1. Łączenie tylko dwóch tabel źródła danych
2. Podłączenie wymaganej liczby tabel źródła danych
3. Łączymy tylko dwie tabele źródła danych i przy co najmniej jednej z tabel należy zaznaczyć checkbox „Wszystkie”
Podstawowy, który ułatwia naukę początkującym programistom. Nie jest to jednak bezpośredni odpowiednik żadnego z wymienionych języków.Oto tylko niektóre z najważniejszych cech wbudowanego języka:
- wstępna kompilacja; przed wykonaniem moduły zawierające tekst w języku wbudowanym są konwertowane na kod wewnętrzny;
- buforowanie skompilowanych modułów w pamięci;
- miękkie typowanie - typ zmiennej jest określony przez rodzaj zawartej w niej wartości i może zmieniać się w trakcie operacji;
- brak opisu programowego obiektów konfiguracyjnych; deweloper może wykorzystać zarówno obiekty wbudowane w platformę, jak i obiekty stworzone przez system w wyniku wizualnego zaprojektowania rozwiązania aplikacyjnego.
Wbudowany język zorientowany na zdarzenia. Przeznaczenie języka wbudowanego w systemie 1C:Enterprise wyznacza ideologia tworzenia rozwiązań aplikacyjnych. Rozwiązania aplikacyjne w 1C:Enterprise 8.0 nie są w pełni zakodowane. Większość rozwiązań aplikacyjnych tworzona jest przez programistę poprzez projektowanie wizualne - tworzenie nowych obiektów konfiguracyjnych, ustawianie ich właściwości, formularzy prezentacji, relacji itp. Wbudowany język służy jedynie do określenia zachowania obiektów rozwiązania aplikacyjnego, które różni się od standardowego oraz tworzenia własnych algorytmów przetwarzania danych.
Z tego powodu moduły zawierające tekst w języku wbudowanym wykorzystywane są przez system w konkretnych, znanych wcześniej sytuacjach, które mogą zaistnieć w trakcie działania rozwiązania aplikacyjnego. Takie sytuacje nazywane są zdarzeniami. Zdarzenia mogą być powiązane z funkcjonowaniem obiektów rozwiązania aplikacyjnego lub z samym rozwiązaniem aplikacyjnym.
Przykładowo z funkcjonowaniem obiektu rozwiązania aplikacji Directory powiązanych jest wiele zdarzeń, wśród których znajduje się zdarzenie BeforeWrite. Zdarzenie to ma miejsce tuż przed zapisaniem danych elementu katalogu do bazy danych. Programista za pomocą wbudowanego języka może opisać algorytm, który np. sprawdzi poprawność danych wprowadzonych przez użytkownika. Umieszczając ten algorytm w odpowiednim module, programista zapewni, że za każdym razem, gdy użytkownik zarejestruje element w katalogu, system wykona algorytm stworzony przez programistę i sprawdzi, czy użytkownik zapomniał uzupełnić wymagane dane katalogu.
Można zatem powiedzieć, że język wbudowany jest językiem skryptowym służącym do programowania logiki biznesowej, a wykorzystanie modułów w języku wbudowanym jest zależne od zdarzenia, tj. moduły są uruchamiane w przypadku wystąpienia określonych zdarzeń podczas działania rozwiązania aplikacyjnego.
Predefiniowane typy danych
Platforma 1C:Enterprise 8.0 umożliwia programiście korzystanie z różnych typów danych.
Istnieje duża liczba typów danych zdefiniowanych na poziomie samej platformy. Na przykład to prymitywne typy danych, takie jak ciąg znaków, liczba, data itp.
Opis prymitywne typy danych:
- ZERO- brakująca wartość. Używany na przykład w zapytaniach.
- Nieokreślony- pusta, niezdefiniowana wartość. Stosuje się go na przykład podczas oceny przekazania parametrów, jeśli parametr ten zostanie pominięty podczas wywoływania procedury lub funkcji. Szczegóły, które mają złożony typ danych, mają domyślnie typ „Niezdefiniowany”.
- Wartość logiczna- zawiera dwie wartości: True lub False. Używany na przykład w wyrażeniach logicznych - wyrażenie logiczne jest typu „Boolean”.
- data- zawiera datę i godzinę. Wartość domyślna to 01.01.01 00:00:00 data rozpoczęcia naszej ery. Czas liczony jest od początku dnia. Wyrażenie, które ma dosłowny typ „data”, zapisuje się w następujący sposób - „00010101000000”. Najpierw zapisywany jest rok, potem miesiąc, następnie data, a na końcu godzina. Możliwy jest następujący wpis: „20041031”. Domyślną godziną jest początek dnia.
- Linia- może mieć zmienną, stałą lub nieograniczoną długość. Ogólnie zaleca się stosowanie ciągów o zmiennej długości.
- Numer- głębokość bitowa liczby została zwiększona do 38 bitów.
- Typ- służy do określenia typów wartości. Używany na przykład do porównywania typów danych. Nie ma literałów i jest zwracany przez funkcje Type(<Имя типа>) lub TypeValue(<Значение>).
Jest ich więcej złożone typy danych. Platforma obsługuje np. szereg typów będących uniwersalnymi zbiorami wartości: tablica, struktura, lista wartości, drzewo wartości itp.
Typy danych „Kolekcje uniwersalne” - lista (zestaw) obiektów danych dowolnego typu, do których wartości można uzyskać dostęp metodą brute-force lub określonym indeksem (kluczem). Numeracja elementów kolekcji zaczyna się od 0. Wszystkie określone typy danych tworzone są wyłącznie programowo.
Szyk. Reprezentuje numerowaną kolekcję wartości dowolnego typu. Dostęp do elementu tablicy można uzyskać poprzez jego indeks. Elementami tablicy mogą być w szczególności inne tablice. Pozwala to na tworzenie tablic wielowymiarowych.
Struktura. Reprezentuje nazwaną kolekcję składającą się z par klucz-wartość. Kluczem może być tylko ciąg znaków, wartość może być dowolnego typu. Dostęp do elementu konstrukcji można uzyskać poprzez wartość jego klucza, tj. wg nazwy. Zwykle używany do przechowywania niewielkiej liczby wartości, każda z unikalną nazwą.
Korespondencja. Podobnie jak Struktura, jest to zbiór par Klucz-Wartość. Jednak w przeciwieństwie do struktury klucz może być niemal dowolnego typu.
Lista wartości. Zwykle używane do rozwiązywania problemów z interfejsem. Pozwala budować dynamiczne zbiory wartości i manipulować nimi (dodawać, edytować, usuwać elementy, sortować). Może zawierać wartości dowolnego typu, ponadto rodzaje przechowywanych wartości na jednej liście mogą być różne.
Tabela wartości. Tabela wartości umożliwia tworzenie dynamicznych zestawów wartości i manipulowanie nimi. Można ją wypełnić wartościami dowolnego typu, a w jednej tabeli typy przechowywanych wartości mogą być różne.
Drzewo wartości. Drzewo wartości to dynamicznie generowany zbiór wartości dowolnego typu, podobny do tabeli wartości. W przeciwieństwie do tabeli wartości wiersze drzewa wartości mogą tworzyć struktury hierarchiczne: każdy wiersz w drzewie może mieć zestaw wierszy podrzędnych, każdy z wierszy podrzędnych może z kolei mieć także zestaw wierszy podrzędnych i tak dalej. W tym przypadku wyszukiwanie wartości, sortowanie i uzyskiwanie wyników może odbywać się albo według aktualnego poziomu hierarchii, albo z uwzględnieniem wszystkich podrzędnych.
COMSafeArray. Reprezentuje opakowanie obiektu na wielowymiarowej tablicy SAFEARRAY
Procedura SelectFromFileClick(Element) // Wybranie pliku za pomocą funkcji ViewFileSelectionDialog = NewFileSelectionDialog(FileSelectionDialogMode.Open); FileSelectionDialog.Directory = ""; FileSelectDialog.Preview = Prawda; FileSelectionDialog.FilterIndex = 0; Jeśli FileSelectDialog.Select() to File = New File(FileSelectDialog.FullFileName); Obraz = NewValueStorage(NewImage(FileSelectionDialog.FullFileName)); Wyświetlać obraz(); koniecJeśli; Koniec procedury
TO_SŁOWO KLUCZOWE
<Это конструкция языка>,
<Это конструкция
языка>
TA_FUNKCJA(<Это конструкция языка>)
W regułach opisujących język zapytań konstrukcje językowe są wskazane w nawiasach ostrych. Słowa kluczowe i nazwy funkcji opisano wielkimi literami.
Konstrukcje językowe mogą zawierać elementy opcjonalne - słowa kluczowe itp. W regułach opisujących język zapytań elementy opcjonalne ujęte są w nawiasy kwadratowe „[” i „]”:
[TO JEST SŁOWO OPCJONALNE] [<Это необязательная конструкция>]
W niektórych przypadkach projekt języka może wykorzystywać jeden z kilku alternatywnych elementów. Takie elementy w zasadach są wymienione za pomocą pionowej kreski „|”:
EITHER_THIS_WORD | LUB TO_SŁOWO
<Либо эта конструкция>
| <Либо эта конструкция>
Opisom wszystkich konstrukcji towarzyszą przykłady wyjaśniające sposób ich użycia w języku zapytań.
Komentarze w języku zapytań
Treść żądania może zawierać komentarze. Za komentarz uważa się część linii rozpoczynającą się od ciągu znaków // i ciągnącą się aż do końca linii:
//To jest komentarz.
Komentarze są ignorowane podczas wykonywania żądania.
Dwujęzyczna reprezentacja słów kluczowych
Jedną z istotnych cech języka zapytań 1C: Enterprise jest to, że podobnie jak w języku wbudowanym wszystkie słowa kluczowe mają dwie pisownię: w języku rosyjskim i angielskim. W dalszej części tego rozdziału wskazana jest rosyjska pisownia słów kluczowych. Poniżej znajduje się tabela przedstawiająca zgodność między językiem rosyjskim i angielskim oraz opcje pisowni słów kluczowych w języku zapytania... (pominięte)
Główne sekcje tekstu żądania
Tekst żądania można opisać następującą regułą:
<Описание запроса>
[<Объединение запросов>]
[<Упорядочивание
результатов>]
[AUTO ZAMÓWIENIE]
[<Описание итогов>]
Jak wynika z tej reguły, tekst żądania składa się z kilku części lub sekcji:
W sekcji<Упорядочивание результатов>Możesz zdefiniować warunki kolejności wierszy w wyniku zapytania. Porządkowanie wyniku zapytania zostało omówione na stronie 324.
AUTO ORDER umożliwia włączenie automatycznej kolejności wierszy w wyniku zapytania. Tryb ten opisano na stronie 331.
W sekcji<Описание итогов>Możesz określić, które sumy mają zostać obliczone w zapytaniu. Ta sekcja jest opisana na stronie 332.
Opis żądania
Jak już wspomniano, tekst żądania musi koniecznie zawierać sekcję z opisem żądania, która definiuje:
Pola, które będą zawarte w wyniku żądania;
Zapytania o źródła danych - tabele źródłowe;
Warunki wpływające na wybór danych w żądaniu;
Kolejność grupowania wyników zapytania.
Sekcja opisu żądania składa się z kilku powiązanych ze sobą zdań:
WYBIERZ [INNE] [PIERWSZE<Количество>]
<Список
полей выборки>
[Z<Список источников>]
[GDZIE<Условие отбора>]
[GRUPUJ WEDŁUG<Поля группировки>]
[MAJĄCY<Условие отбора>]
[DO ZMIANY [<Список таблиц верхнего уровня>]]
Opis żądania zaczyna się od wymaganego słowa kluczowego WYBIERAĆ.
Oferta GDZIE<Условие отбора> umożliwia filtrowanie wyniku zapytania. Wynik uwzględnia tylko te rekordy, dla których określony warunek jest spełniony. Zasady opisywania warunków selekcji zostały omówione na stronie 315.
Oferta DLA ZMIANY ma na celu sygnalizowanie konieczności zablokowania danych odczytywanych w transakcji.
Oferta GRUPA pozwala opisać kolejność grupowania wyników zapytania. Grupowanie zostało szczegółowo omówione na stronie 316.
Oferta MAJĄCY umożliwia nałożenie warunków na wyniki grupowania. Opisano na stronie 318.
Wszystkie przykłady zapytań w tym rozdziale zawierają tekst zapytania i wynik zapytania. Zakłada się, że tekst żądania jest przekazywany jako parametr do metody Execute obiektu Request.
Podajmy przykład dość prostego zapytania składającego się z jednej instrukcji SELECT i listy pól selekcji.
//Musisz wyświetlić w raporcie listę faktur.
Wynik zapytania:
Użycie słowa INNY
W wielu sytuacjach pożądane jest, aby te same wiersze w raporcie się nie powtarzały.
// Należy ogólnie dowiedzieć się, którzy kontrahenci
// towary zostały wysłane w danym okresie.
Wybierz opcję Dokument.Faktura.Kontrahent
Wynik zapytania:
Można zauważyć, że wynik zapytania zawiera wiele powtarzających się linii, co zmniejsza jego przejrzystość. Aby uniknąć powtórzeń, w opisie zapytania należy podać słowo kluczowe DIFFERENT.
Wybierz opcję Różne dokumenty. Faktura. Kontrahent
Wynik zapytania:
Użycie słowa PIERWSZY
W niektórych przypadkach konieczne jest wyświetlenie w raporcie ograniczonej liczby wierszy. W tym celu w opisie zapytania należy podać słowo kluczowe FIRST, a po nim wymaganą liczbę wierszy.
// Należy wybrać pięć najdroższych towarów.
// Wyboru należy dokonać w kolejności malejącej ceny produktu.
Wybierz Pierwsze 5
Katalog.Nomenklatura.Nazwa,
Katalog.Nomenklatura.Cena zakupu
Sortuj według katalogu.Nomenklatura.PurchaseCena malejąco
Wynik zapytania:
Opis pól wyboru
Po obowiązkowym słowie kluczowym SELECT (oraz słowach kwalifikujących DIFFERENT i FIRST) w tekście żądania podawana jest lista pól wyboru. Pola te będą przetwarzane podczas pobierania danych w żądaniu. Wynik zapytania będzie również zawierał zestaw pól zdefiniowanych na tej liście. Pola wyboru opisane są według następujących zasad:
<Описание поля>[ [JAK]<Псевдоним поля>]
<Выражение>[.<Группа полей>]
Lista pól wyboru składa się z jednego lub większej liczby elementów oddzielonych przecinkami. Każdy<Поле выборки>składa się z opisu pola wyboru oraz opcjonalnego aliasu pola.
Zamiast umieszczać pola na liście wyboru, możesz wpisać gwiazdkę „*”. Będzie to oznaczać, że wynik zapytania musi zawierać wszystkie pola, które znajdują się w tabelach źródłowych – czyli źródłach danych zapytania opisanych na liście źródeł.
Komentarz! W przypadku podania gwiazdki „*” na liście pól wyboru, pola wirtualne tabel źródłowych nie zostaną uwzględnione w wyniku.
<Описание поля>określa w jaki sposób powinny być generowane wartości pól. W najprostszym przypadku pole wyboru jest odnośnikiem do pola w tabeli źródłowej. Link można określić określając tabelę zawierającą to pole lub bez podawania samej tabeli. Dereferencje pól są omówione pod adresem.
Ogólnie rzecz biorąc, pole wyboru może być nie tylko linkiem do pola w tabeli źródłowej, ale także jakimś<Выражение>. Wyrażenia są szczegółowo omówione na stronie 344.
Wyniki zapytania można grupować przy użyciu funkcji agregujących określonych jako wyrażenia w wybranych polach. Grupowanie wyników zapytań zostało omówione na stronie 316. Funkcje agregujące opisano na stronie 345.
Do każdego pola wyboru można przypisać alias. W przyszłości można go wykorzystać do wygodniejszego dostępu do tego pola. Poniżej omówiono użycie aliasów pól.
<Группа полей>można określić tylko wtedy, gdy pole wyboru wskazuje na zagnieżdżoną tabelę. W takim przypadku możesz określić, które pola mają być przetwarzane przy wyborze tabeli zagnieżdżonej. Jeśli grupa pól nie zostanie określona, podczas selekcji zostaną przetworzone wszystkie pola tabeli zagnieżdżonej. Dostęp do zagnieżdżonych tabel opisano w .
Aliasy pól na liście wyboru
Jeśli do pola wyboru zostanie przypisany alias, można później odwoływać się do tego pola, korzystając z jego aliasu w klauzulach ORDER BY i TOTAL, a także podczas pracy z wynikiem zapytania. Takie leczenie może być wygodniejsze i wizualne, a w niektórych przypadkach jedyne możliwe.
Słowo kluczowe HOW może poprzedzać alias pola. To słowo może w ogóle nie zostać określone, ale jeśli zostanie określone, zwiększa się widoczność i czytelność tekstu żądania.
Aliasy pól ustawiane są zgodnie z zasadami nadawania identyfikatorów zmiennych. Aliasy w żądaniu nie mogą być takie same.
Przypisanie aliasów do pól samo w sobie nie wpływa na wybór danych w zapytaniu.
// Należy wybrać z katalogu produktów
// nazwy towarów i nazwy grup.
Wybierać
Informator. Nomenklatura Nazwa jako produkt,
Informator. Nomenklatura.Nazwa rodzica.Jako grupa
z
Katalog.Nomenklatura
Wynik zapytania:
Należy pamiętać, że pola w wyniku zapytania o pole noszą nazwy „Element” i „Grupa”. Jeżeli aliasy pól nie zostały określone, pola w wyniku zapytania będą miały nazwy „Nazwa” i „Nazwa 1” (nazwy pól w wyniku zapytania nie mogą się zgadzać, dlatego do nazwy drugiego pola automatycznie dodawana jest wartość „1”), co jest znacznie mniej jasne.
Zagnieżdżone tabele na liście pól wyboru
Pole na liście wyboru może odwoływać się do zagnieżdżonej tabeli w źródle danych zapytania. W tym przypadku pole wyniku zapytania będzie typu Query Result, czyli będzie zawierało zagnieżdżony wynik zapytania wygenerowany na podstawie zagnieżdżonej tabeli źródłowej.
Domyślnie w wyniku zagnieżdżenia uwzględniane są wszystkie pola tabeli zagnieżdżonej – źródła danych. Możliwe jest jawne zdefiniowanie grupy pól, które powinny znaleźć się w wyniku zagnieżdżonego zapytania. Grupa zagnieżdżonych pól wynikowych opisana jest według następującej reguły:
(<Список вложенных полей>) | *
<Вложенное поле [, <Вложенное поле>[, ...] ]
<Список вложенных полей>składa się z jednego lub większej liczby elementów oddzielonych przecinkami. Jeśli lista składa się z jednego elementu, nie trzeba jej podawać w nawiasach.
Zamiast wyświetlać zagnieżdżone pola, możesz umieścić gwiazdkę „*”; będzie to oznaczać, że wynik zagnieżdżonego zapytania musi zawierać wszystkie pola znajdujące się w zagnieżdżonej tabeli.
<Выражение>[[JAK]<Псевдоним поля>]
<Вложенное поле>może reprezentować pewne wyrażenie. W najprostszym przypadku<Выражение>jest odniesieniem do pola w zagnieżdżonej tabeli. Wyrażenia są szczegółowo omówione na stronie 344.
Każdemu zagnieżdżonemu polu można przypisać alias. Dalej<Псевдоним поля>można wykorzystać w celu wygodniejszego dostępu do tego pola, podobnie jak aliasy dla pól na liście wyboru - patrz rozdział „Aliasy dla pól na liście wyboru” na stronie
Aliasy można przypisywać do pól zagnieżdżonych niezależnie od tego, czy alias jest przypisany do samej tabeli zagnieżdżonej.
//Konieczne jest wyświetlenie w raporcie specyfikacji faktur,
// sam dokument, nazewnictwo i ilość.
Wybierać
Dokument.Faktura.Skład.(Nomenklatura jako produkt, ilość)
Wynik zapytania:
Połączyć Mieszanina Produkt Ilość Dżinsy dla kobiet 4 Dżinsy dla kobiet 5 Koszula "Kowbojka" 5 Faktura 00005 z dnia 24.02.2002 0:00:00 Dżinsy dla kobiet 1 Dżinsy dla kobiet 1 Moydodyr „Akwarium” 5 Zlew „Lilia” 8 Mikser „Ultra” 10
Należy pamiętać, że pole „Skład” wyniku zapytania jest zagnieżdżoną tabelą zawierającą pola „Nomenklatura” i „Ilość”.
//Wyświetl w raporcie wszystkie pola części tabelarycznej faktury.
Wybierać
Dokument.Faktura.Link,
Dokument.Faktura.Skład.*
Celem klauzuli IZ jest wyznaczenie listy tabel źródłowych – źródeł danych wykorzystywanych w danej instrukcji SELECT.
Należy zaznaczyć, że klauzula IZ w języku zapytań jest opcjonalna. Można go pominąć, jeśli źródła danych są w pełni kwalifikowane w opisie listy pól selekcji zawartej w klauzuli SELECT. Należy pamiętać, że wiele przykładów z poprzednich sekcji nie zawierało klauzuli IZ.
Po słowie kluczowym IZ wskazywana jest lista źródeł. Generalnie listę źródeł opisuje następujący zestaw reguł:
<Источник>[, <Источник>[, ...]]
Źródła danych zapytań są wymienione na liście źródeł, oddzielone przecinkami. Każdy<Источник>wykaz źródeł musi zawierać opis źródła; ponadto można to określić<Перечень соединений>- zasady łączenia źródła z innymi źródłami. Opisano specyfikacje połączeń.
<Описание источника> [ <Перечень соединений> ]
Jeśli źródłem danych jest tabela bazy danych,<Описание источника>zawiera<Имя таблицы>.
<Таблица>[ [JAK]<Псевдоним источника>]
Jeśli tabela źródłowa jest wirtualna, możesz określić<Параметры>jego powstanie. Parametry tabeli wirtualnej zostały szczegółowo opisane w sekcji „Źródła danych zapytań”.
<Имя таблицы> [(<Параметры>)] | <Описание запроса>
Podzapytanie może również działać jako źródło danych zapytania; w tym przypadku zawiera opis źródłowy<Описание запроса>. Użycie zapytań zagnieżdżonych opisano na stronie.
W opisie źródła danych można także przypisać jego alias. Dalej<Псевдоним источника>można wykorzystać do wygodniejszego dostępu do tego źródła. Korzystanie z aliasów źródeł danych jest omówione na stronie.
Specyfikacje połączeń
Podczas definiowania wielu źródeł na liście źródłowej dla każdego rekordu z pierwszej tabeli źródłowej dokonywany jest wybór z drugiej tabeli źródłowej i tak dalej. Zatem zapytanie daje wszystkie możliwe kombinacje wszystkich rekordów ze wszystkich określonych źródeł.
Wynik zapytania:
Kontrahent Bank Dostawcy JSCB InvestBank Dostawcy JSCB PromStroyBank Fabryka Dziewiarska „Zaria” JSCB InvestBank Fabryka Dziewiarska „Zaria” JSCB PromStroyBank Fabryka odzieży dżinsowej JSCB InvestBank Fabryka odzieży dżinsowej JSCB PromStroyBank Kupujący JSCB InvestBank Kupujący JSCB PromStroyBank Targi odzieżowe JSCB InvestBank Targi odzieżowe JSCB PromStroyBank Dom handlowy „Budenovsky” JSCB InvestBank Dom handlowy „Budenovsky” JSCB PromStroyBank Pawilon 45 na rynku hurtowym JSCB InvestBank Pawilon 45 na rynku hurtowym JSCB PromStroyBank Bawaria - porcelana JSCB InvestBank Bawaria - porcelana JSCB PromStroyBank Fabryka odzieży dżinsowej JSCB InvestBank Fabryka odzieży dżinsowej JSCB PromStroyBank JSCB PromStroyBank JSCB InvestBank JSCB PromStroyBank JSCB PromStroyBank
Wynik zapytania zawiera kombinacje wszystkich kontrahentów ze wszystkimi bankami. Z reguły taki wynik sam w sobie nie ma sensu. Zwykle kombinacje rekordów z różnych tabel źródłowych muszą być ograniczone pewnymi warunkami. W języku zapytań można opisać taką kombinację źródeł poprzez określenie samych źródeł i określenie warunków, na jakich kombinacje rekordów z tych źródeł muszą zostać uwzględnione w wyniku zapytania.
Istnieje kilka rodzajów połączeń, opisują je następujące zasady:
<Соединение> [<Перечень соединений>]
Ogólnie<Перечень соединений>może zawierać i opisywać nie tylko jedno połączenie (dwóch źródeł), ale także kilka połączeń kilku źródeł jednocześnie.
[WEWNĘTRZNY] DOŁĄCZ<Описание источника>PRZEZ<Условие отбора> |
LEWY [ZEWNĘTRZNY] DOŁĄCZ<Описание источника>PRZEZ<Условие отбора> |
PRAWY [ZEWNĘTRZNY] DOŁĄCZ<Описание источника>PRZEZ<Условие отбора> |
PEŁNE (ZEWNĘTRZNE) POŁĄCZENIE<Описание источника>PRZEZ<Условие отбора>
<Условие отбора>zawiera warunki według których selekcja musi łączyć dane z oryginalnych tabel - źródeł zapytania. Zasady opisywania warunków w języku zapytań omówione są na stronie 357.
Słowa kluczowe LEFT, RIGHT i FULL wyjaśniają naturę połączenia. Słów WEWNĘTRZNYCH lub ZEWNĘTRZNYCH nie można w ogóle umieszczać, zwiększają one przejrzystość i czytelność tekstu żądania.
Łączone źródła nie są sobie równoważne i w niektórych przypadkach wynik zależy od tego, która tabela jest wymieniona jako pierwsza, przed słowem kluczowym JOIN (po lewej stronie), a która tabela jest wymieniona jako druga (po prawej).
[INTERNAL] JOIN oznacza, że z obu tabel źródłowych – źródeł danych, w wyniku zapytania muszą zostać uwzględnione tylko te kombinacje rekordów, które spełniają określony warunek. Pozostałe rekordy nie są uwzględniane w wyniku.
// Trzeba dowiedzieć się, które banki są w tym samym czasie
// kontrahenci (występują te same nazwy
//zarówno w katalogu Kontrahenci, jak i w katalogu Banki).
Wybierać
Banki.Link Jak korzystać z banku
Z
Połączenie wewnętrzne
Katalog.Banki Jak Banki
Przez
Wynik zapytania:
Kontrahent Bank JSCB PromStroyBank JSCB PromStroyBank
LEFT [OUTER] JOIN oznacza, że wynik zapytania musi zawierać kombinacje rekordów z obu tabel źródłowych, które spełniają określony warunek. Jednak w przeciwieństwie do łączenia wewnętrznego wynik zapytania musi także zawierać rekordy z pierwszego źródła (wskazane po lewej stronie słowa JOIN), dla których nie znaleziono żadnych rekordów z drugiego źródła spełniających warunek.
W ten sposób wynik zapytania będzie zawierał wszystkie rekordy z pierwszego źródła; zostaną one połączone z rekordami z drugiego źródła, jeśli zostanie spełniony określony warunek. Wiersze wyników zapytania, dla których nie znaleziono rekordów z drugiego źródła spełniających warunek, będą zawierać NULL w polach wygenerowanych na podstawie rekordów z tego źródła.
//Konieczne jest wyświetlenie w raporcie wszystkich kontrahentów i dla nich
// kto jest jednocześnie bankiem - podaj link do banku.
Wybierać
Kontrahenci. Połącz jako kontrahenta,
Banki.Link Jak korzystać z banku
Z
Katalog Kontrahenci Jak Kontrahenci
Lewe połączenie zewnętrzne
Katalog.Banki Jak Banki
Przez
Counterparties.Name = Banks.Name
Wynik zapytania:
RIGHT [OUTER] JOIN oznacza, że wynik zapytania musi zawierać kombinacje rekordów z obu tabel źródłowych, które spełniają określony warunek. Dodatkowo w wyniku zapytania muszą zostać uwzględnione także rekordy z drugiego źródła (wskazane na prawo od słowa POŁĄCZENIE), dla których nie znaleziono żadnych rekordów z pierwszego źródła spełniających warunek.
Zatem wynik zapytania będzie zawierał wszystkie rekordy z drugiego źródła; zostaną one połączone z rekordami z pierwszego źródła, jeśli zostanie spełniony określony warunek. Wiersze wyników zapytania, dla których nie znaleziono rekordów z pierwszego źródła spełniających warunek, będą zawierać NULL w polach wygenerowanych na podstawie rekordów z tego źródła.
//Konieczne jest wyświetlenie w raporcie wszystkich banków i dla nich
// kto jest jednocześnie kontrahentem - podaj link do kontrahenta.
WYBIERAĆ
Kontrahenci. Połącz jako kontrahenta,
Banki.Link jak bank
Z
Katalog Kontrahenci Jak Kontrahenci
Prawe połączenie zewnętrzne
Katalog.Banki Jak Banki
Przez
Counterparties.Name = Banks.Name
Wynik zapytania:
Kontrahent Bank ZERO JSCB InvestBank JSCB PromStroyBank JSCB PromStroyBank
FULL [OUTER] JOIN oznacza, że wynik zapytania musi zawierać kombinacje rekordów z obu tabel źródłowych, które spełniają określony warunek. Dodatkowo w wyniku zapytania muszą zostać uwzględnione także te rekordy z obu źródeł, dla których nie znaleziono żadnych dopasowań.
W ten sposób wynik zapytania będzie zawierał wszystkie rekordy z obu źródeł; zostaną one ze sobą połączone, gdy spełniony zostanie określony warunek. Wiersze wyników zapytania, dla których nie znaleziono rekordów z żadnego źródła spełniających warunek, będą zawierać NULL w polach wygenerowanych na podstawie rekordów z tego źródła.
// Konieczne jest wyświetlenie w raporcie wszystkich kontrahentów i wszystkich banków,
// a ci, którzy są obydwoma - drukują w jednej linii.
Wybierać
Kontrahenci. Połącz jako kontrahenta,
Banki.Link Jak korzystać z banku
Z
Katalog Kontrahenci Jak Kontrahenci
Pełne połączenie zewnętrzne
Katalog.Banki Jak Banki
Przez
Counterparties.Name = Banks.Name
Wynik zapytania:
Aliasy źródeł danych
Jeśli przypiszesz alias do źródła danych, w przyszłości dostęp do tego źródła będzie można uzyskać przy użyciu tego aliasu (i nie będzie już można uzyskać do niego dostępu poprzez określenie nazwy tabeli). Takie leczenie może być wygodniejsze i wizualne, a w niektórych przypadkach jedyne możliwe.
Alias ustawiany jest zgodnie z zasadami nadawania identyfikatorów zmiennych. Aliasy w żądaniu nie mogą być takie same.
Słowo kluczowe HOW może poprzedzać alias źródłowy. To słowo może w ogóle nie zostać określone, ale jeśli zostanie określone, zwiększa się widoczność i czytelność tekstu żądania.
Przypisanie aliasów do źródeł samo w sobie nie wpływa na wybór danych w zapytaniu.
// Ten przykład ilustruje użycie
// na liście pól wyboru aliasu Produkt,
// przypisany do tabeli źródłowej Directory.Nomenclature
Wybierać
Nazwa produktu,
Produkt.Nadrzędny
Z
Katalog.Nomenklatura.Produkt
Zagnieżdżone tabele na liście źródłowej
Na liście źródeł mogą znajdować się także tabele zagnieżdżone – części tabelaryczne podręczników i dokumentów.
//Konieczne jest wyświetlenie w raporcie specyfikacji faktur -
// pokaż sam dokument, nazewnictwo i ilość.
//Lista źródeł zawiera zagnieżdżoną tabelę „Kompozycja” -
// tabelaryczna część faktury.
// Wybór jest ograniczony do ośmiu rekordów, aby nie przeciążać przykładu.
Wybierz Pierwsze 8
Link, nazewnictwo, ilość
Z
Dokument.Faktura.Skład
Wynik zapytania:
Połączyć Nomenklatura Ilość Faktura 00007 z dnia 25.02.2002 21:03:21 Dżinsy dla kobiet 4 Faktura 00006 z dnia 25.02.2002 0:00:00 Dżinsy dla kobiet 5 Faktura 00006 z dnia 25.02.2002 0:00:00 Koszula "Kowbojka" 5 Faktura 00005 z 01.03.2002 20:58:28 Dżinsy dla kobiet 1 Faktura 00004 z dnia 01.03.2002 20:50:40 Dżinsy dla kobiet 1 Faktura 00003 z dnia 23.02.2002 0:00:00 Moydodyr „Akwarium” 5 Faktura 00003 z dnia 23.02.2002 0:00:00 Zlew „Lilia” 8 Faktura 00003 z dnia 23.02.2002 0:00:00 Mikser „Ultra” 10
Należy pamiętać, że w przypadku określenia tabeli zagnieżdżonej na liście źródeł możliwy jest dostęp zarówno do pól samej tabeli zagnieżdżonej, jak i do pól tabeli najwyższego poziomu (tej, która zawiera tabelę zagnieżdżoną). W takim przypadku uzyskuje się dostęp do pola „Link” samego dokumentu.
Podzapytania na liście źródłowej
Na liście źródeł zapytań podzapytanie może służyć jako tabela źródłowa. W tym przypadku opis źródła zawiera opis podzapytania. Opis zapytania zagnieżdżonego jest kompilowany dokładnie w taki sam sposób, jak zwykłego: patrz
Używanie zagnieżdżonego zapytania jako źródła danych nie różni się od używania tabeli bazy danych. Wszystkie pola opisane na liście pól wyboru podzapytań są dostępne jako pola takiego źródła.
Wynik będzie dokładnie taki sam jak w poprzednim przykładzie.
Generowanie raportów
Praca z prośbami
Do pracy z zapytaniami używany jest wbudowany obiekt językowy Wniosek . Pozwala uzyskać informacje zapisane w polach bazy danych w postaci próbki utworzonej według określonych reguł.
Zapytania o źródła danych
Zapytanie pobiera początkowe informacje ze zbioru tabel. Tabele te przedstawiają dane z rzeczywistych tabel bazy danych w łatwej do analizy formie. Można je podzielić na dwie duże grupy: realne i wirtualne.
Z kolei tabele rzeczywiste mogą być obiektowe (odniesienie) lub nieobiektowe (brak odniesienia):
Cechą charakterystyczną tabel rzeczywistych jest to, że zawierają one dane z jednej tabeli rzeczywistej przechowywanej w bazie danych. Przykładowo tabelami rzeczywistymi są tabela „Katalog.Klienci” odpowiadająca katalogowi „Klienci” lub tabela „Rejestr akumulacji. Pozostały materiał” odpowiadająca rejestrowi akumulacji „Pozostały materiał”.
Tabele wirtualne tworzone są głównie z danych z wielu tabel bazy danych. Przykładowo wirtualną tabelą jest tabela „Rejestr akumulacji. Pozostałości materiałowe. Bilanse i obroty”, utworzona z kilku tabel rejestru akumulacji „Pozostałości materiałowe”. Czasami tabele wirtualne można utworzyć z jednej tabeli rzeczywistej (np. tabela wirtualna „Ceny.SliceLast” tworzona jest na podstawie tabeli rejestru informacyjnego „Ceny”). Jednak wspólną cechą wszystkich tabel wirtualnych jest to, że można im nadać szereg parametrów, które określą, jakie dane zostaną zawarte w tych wirtualnych tabelach. Zestaw takich parametrów może być różny dla różnych wirtualnych tabel i jest wyznaczany na podstawie danych przechowywanych w źródłowych tabelach bazy danych.
Tabele rzeczywiste dzielą się na tabele obiektowe (referencyjne) i tabele nieobiektowe (niereferencyjne).
Tabele obiektowe (referencyjne) dostarczają informacji o typach danych referencyjnych (katalogi, dokumenty, plany typów cech itp.). A w przypadku nieobiektowym (niereferencyjnym) - wszystkie inne typy danych (stałe, rejestry itp.).
Cechą charakterystyczną tabel obiektowych (referencyjnych) jest to, że zawierają one pole „Link” zawierające odnośnik do bieżącego rekordu. Dodatkowo dla takich tabel istnieje możliwość uzyskania własnej reprezentacji obiektu, tabele te mogą mieć charakter hierarchiczny, a pola takich tabel mogą zawierać tabele zagnieżdżone (części tabeli).
Język zapytań
Algorytm, według którego zostaną wybrane dane z tabel źródłowych żądania, opisany jest w tekście żądania w specjalnym języku - język zapytań. Tekst żądania składa się z kilku części:
opis żądania,
łączenie zapytań
zamawianie wyników,
automatyczne zamawianie,
opis wyników.
Jedyną obowiązkową częścią żądania jest część pierwsza – opis żądania. Wszyscy pozostali są obecni w miarę potrzeb.
Opis żądania definiuje źródła danych, pola wyboru, grupowania itp.
Łączenie zapytań określa sposób łączenia wyników wielu zapytań.
Organizowanie wyników definiuje warunki porządkowania wierszy wyników zapytania.
Automatyczne zamówienie umożliwia włączenie automatycznej kolejności wierszy wyników zapytania.
Opis wyników określa, jakie sumy należy obliczyć w zapytaniu i jak grupować wyniki.
Raport Rejestru Dokumentów Świadczenia Usług
Pierwszym raportem, na podstawie którego zaczniemy zapoznawać się z językiem zapytań, będzie raport „Rejestr dokumentów świadczenia usług”. Raport ten po prostu wyświetli listę dokumentów „Świadczenia usług” istniejących w bazie danych, w kolejności ich dat i numerów.
Stwórzmy w konfiguratorze nowy obiekt konfiguracyjny: Raport „Rejestr Dokumentów Świadczenia Usług”. Przejdźmy do zakładki „Układ” i uruchommy projektanta formularzy wyjściowych.
Jako źródło danych dla żądania wybierzemy obiektową (referencyjną) tabelę dokumentów „Świadczenie usług”. Z tej tabeli wybieramy następujące pola:
"Gospodarz",
"Klient":
Należy pamiętać, że w przypadku wybrania pól „Magazyn”, „Główny” i „Klient”, na liście wybranych pól zaznaczone zostaną również pola „Magazyn.Widok”, „Master.Widok” i „Widok klienta”. Faktem jest, że w ogólnym przypadku zakłada się, że pola te będą wyświetlane w komórkach dokumentu arkusza kalkulacyjnego. Ponieważ odpowiadające im pola „Magazyn”, „Magazyn” i „Klient” są polami referencyjnymi, jeżeli wartość referencyjna zostanie przekazana jako wartość parametru dla wyjścia, system wykona dodatkowe żądanie uzyskania reprezentacji tego pola (która będzie wyświetlane w dokumencie), co skutkuje wolniejszym generowaniem raportów. Dlatego przy wyborze pól referencyjnych system oferuje natychmiastowe uwzględnienie reprezentacji pól referencyjnych na liście wybranych pól, w oczekiwaniu, że zostaną one wykorzystane do wyprowadzenia do dokumentu.
Następnie przejdźmy do zakładki „Zamówienie” i wskażmy, że wynik zapytania należy najpierw uporządkować według wartości pola „Data”, a następnie wartości pola „Świadczenie usługi. Link”:
Przejdźmy do zakładki „Raport” i zresetujmy flagę „Użyj kreatora raportów”:
Zresetujmy flagę „Użyj narzędzia do tworzenia raportów”...
Kliknij OK". Projektant wygeneruje formularz i układ raportu. Otwórzmy moduł formularza i znajdźmy w nim procedurę „Rejestracja dokumentów świadczenia usług”. W tej procedurze jak zostanie wygenerowany tekst żądania, który posłuży do pozyskania interesujących nas danych:
Query.Text = „WYBIERZ
Świadczenie usług. Data AS Data,
Świadczenie Usług Numer AS Numer,
Świadczenie Usług Magazyn,
Świadczenie usług Magazyn Prezentacja,
Świadczenie usług Mistrzu,
Świadczenie usług Mistrz Prezentacja,
Świadczenie Usług Klient,
Świadczenie Usług Klient Reprezentacja
Dokument.Świadczenie usług JAK świadczyć usługi
SORTUJ WEDŁUG
Tekst żądania zaczyna się, jak powiedzieliśmy powyżej, od części opisu żądania:
I Świadczenie usługi Data AS Data,
I Świadczenie usług Numer AS Numer,
I Świadczenie Usług Magazyn,
I Świadczenie usług Magazyn Prezentacja,
I Świadczę usługi Mistrzu,
I Świadczenie usług Mistrz Prezentacja,
I Świadczenie Usług Klient,
1 Świadczenie usług Klienci Reprezentacja
Dokument I. Świadczenie usług JAK świadczyć usługi
Opis żądania zaczyna się od wymaganego słowa kluczowego WYBIERAĆ. Następnie następuje lista wybranych pól opisująca pola, które powinny znaleźć się w wyniku zapytania. Lista ta może zawierać zarówno same pola, jak i niektóre wyrażenia obliczone na podstawie wartości pól.
Po słowie kluczowym IZ wskazane są źródła danych - oryginalne tabele zapytań, których zawartość jest przetwarzana w zapytaniu. W tym przypadku jest to tabela obiektowa (referencyjna) „Dokument.Świadczenie usługi”. Po słowie kluczowym JAK wskazany pseudonimźródło danych. W naszym przypadku jest to „Świadczenie usług”. W przyszłości dostęp do tego źródła danych będzie można uzyskać w treści żądania za pomocą aliasu.
To wywołanie widzimy w opisie pól wyboru:
| Świadczenie usług. Data AS Data,
| Świadczenie Usług Numer AS Numer,
| Świadczenie Usług Magazyn,
| Świadczenie usług Magazyn Prezentacja,
| Świadczenie usług Mistrzu,
| Świadczenie usług Mistrz Prezentacja,
| Świadczenie Usług Klient,
| Świadczenie Usług Klient Reprezentacja
Pola wyboru mogą mieć również aliasy, których można użyć w dalszej części tekstu żądania, aby odnieść się do tego pola. W naszym przypadku są to aliasy „Data” i „Numer”.
Po części opisowej zapytania w naszym przykładzie następuje część porządkująca wyniki:
| ZAMÓW PRZEZ
| Data, | Numer";
Oferta SORTUJ WEDŁUG umożliwia sortowanie wierszy w wyniku zapytania. Po tej kluczowej klauzuli następuje wyrażenie porządkujące, które ogólnie jest listą pól (wyrażeń) i kolejnością wyników. W naszym przypadku uporządkowanie zostanie dokonane w pierwszej kolejności poprzez pole wyboru, do którego dostęp można uzyskać poprzez alias - „Kod”, a następnie poprzez pole - „Numer”. W obu przypadkach porządek sortowania będzie rosnący i jest to domyślny porządek sortowania.
Zwróćmy teraz uwagę na sposób wyświetlania wyniku zapytania w dokumencie arkusza kalkulacyjnego.
Procedura Rejestru Dokumentów Świadczenia Usług (TabDoc) Eksport
//((CONSTRUCTOR_OUTPUT_FORM(Rejestr Dokumentów Świadczenia Usług)// Fragment ten zbudował konstruktor.// Podczas ponownego użycia konstruktora// wprowadzony ręcznie zmiany będzie zgubiony!!!
Layout = GetLayout("Rejestr dokumentów świadczących usługi"); Żądanie = Nowe żądanie;
Wynik = Query.Run();
HeaderArea = Układ.GetArea("Nagłówek"); Powierzchnia piwnicy =
Układ.GetArea("Stopka tabeli"); ObszarRekordówSzczegółowych =
TabDoc.Output(Obszar nagłówka tabeli); TabDoc.StartAutogruttingRows();
SelectDetails = Wynik.Wybierz();
Podczas gdy SelectDetails.NextFunctions() jest pętlą
AreaDetailRecords.Parameters.Fill(SelectionDetails);
TabDoc.Output(RecordsDetailsArea,DetailsSelection.Level()); Koniec cyklu;
/L)CONSTRUCTOR_OUTPUT_FORM Procedura końcowa
Formularz raportu zawiera element kontrolny Pole dokumentu tabelarycznego o nazwie „TabDoc”, który jest wypełniony danymi na podstawie układu wygenerowanego przez projektanta.
Na początku procedury uzyskujemy układ raportu, z którego następnie wyodrębniamy istniejące w nim obszary na odpowiednie zmienne:
HeaderArea = Układ.GetArea("Nagłówek"); Powierzchnia piwnicy =
Układ.GetArea("Piwnica"); Obszar nagłówka tabeli =
Układ.GetArea("Nagłówek tabeli"); Obszar stopki tabeli =
Layout.GetArea("TableFooter"");DetailRecordsArea =
Układ.GetArea("Szczegóły");
Następnie czyścimy dokument arkusza kalkulacyjnego i wyświetlamy te obszary, które nie zawierają danych uzyskanych z wyniku zapytania:
TabDoc.Wyczyść(); TabDoc.Output(Nagłówek obszaru);
TabDoc.Output(Obszar nagłówka tabeli); TabDoc.StartAutoGroupingRows();
W ostatniej linii projektant dodał początek automatycznego grupowania wierszy. W tym przykładzie nie mamy wierszy wymagających pogrupowania, ale domyślnie projektant zawsze sugeruje grupowanie wierszy w dokumencie arkusza kalkulacyjnego. To wywołanie nie wpłynie na szybkość generowania raportu, dlatego pozostawimy tekst konstruktora bez zmian.
Następnie z wyniku zapytania otrzymujemy wybór, przez który przechodzimy w pętli:
W każdej iteracji pętli wypełniamy parametry uzyskanego wcześniej obszaru układu wartościami uzyskanymi z kolejnego przykładowego rekordu wyniku zapytania i wyświetlamy ten obszar w dokumencie arkusza kalkulacyjnego.
Na koniec procedury wyświetlamy końcowe obszary układu w dokumencie arkusza kalkulacyjnego:
TabDoc.FinishAutoGroupingRows();
TabDoc.Output(Obszar tabeli);
TabDoc.Output(AreaFooter);
Teraz uruchommy 1C:Enterprise w trybie debugowania i spójrzmy na wynik naszego raportu:
Zatem na przykładzie tego raportu zademonstrowaliśmy, jak korzystać z projektanta formularzy wyjściowych i zaznajomiliśmy się z kilkoma podstawowymi konstrukcjami języka zapytań.
Raport „Ocena usług” będzie zawierał informację, które usługi przyniosły Master of All Trades LLC największy zysk w określonym okresie. Na przykładzie raportu „Ocena usługi” pokażemy jak wybrać dane w danym okresie, jak ustawić parametry zapytania oraz jak wykorzystać w zapytaniu dane z kilku tabel i uwzględnić w zapytaniu wszystkie dane z jednego ze źródeł wynik zapytania.
Utwórzmy nowy obiekt konfiguracyjny „Raport oceny usług”. Przejdźmy do zakładki „Układy” i wywołajmy konstruktor formularza wyjściowego.
Wybierzmy tabelę obiektową (referencyjną) katalogu „Nomenklatura” oraz wirtualną tabelę rejestru akumulacji „Sprzedaż.Obrót”. Aby wyeliminować niejednoznaczność nazw w zapytaniu zmieniamy nazwę tabeli „Nomenklatura” na „SprNomenklatura” (menu kontekstowe wyświetlane prawym przyciskiem myszy).
Następnie umieść kursor na tabeli „SalesTurnover” i wywołaj okno dialogowe umożliwiające wprowadzenie parametrów wirtualnej tabeli:
Otwórz okno dialogowe do wprowadzania parametrów tabeli wirtualnej
Wskażmy, że początek i koniec okresu zostaną przekazane w odpowiednich parametrach „StartDate” i „EndDate” (symbol „&” przed nazwą wskazuje, że jest to parametr żądania):
Następnie wybierz z tabel pola „SprNomenclature.Link” i „SalesTurnover.RevenueTurnover”:
SprNomenklatura.Prezentacja
Obrót sprzedażyPrzychódObrót
Przejdźmy do zakładki „Linki” i zobaczmy, że projektant stworzył już połączenie pomiędzy dwiema wybranymi tabelami – wartość zmiany rejestru „Nomenklatura” powinna być równa odwołaniu do elementu katalogu „Nomenklatura”.
Jedyne, co nam pozostało, to zresetować flagę „Wszystkie” dla tabeli rejestrów i ustawić ją dla tabeli katalogów.
Wszystkie elementy wybierzemy z katalogu „Nomenklatura”.
Ustawienie flagi „Wszystkie” w tabeli katalogu będzie oznaczać, że z katalogu zostaną wybrane wszystkie elementy i tym elementom zostanie przypisana wartość obrotu przychodowego z rejestru. Zatem w wyniku żądania wszystkie usługi będą obecne, a dla niektórych z nich zostanie wskazany obrót przychodowy. W przypadku usług, które nie zostały zrealizowane w wybranym okresie, nic nie zostanie wskazane.
Przejdźmy do zakładki „Warunki” i ustawmy warunki wyboru elementów z katalogu „Nomenklatura”. Przy ustalaniu warunków selekcji ponownie skorzystamy z parametrów zapytania. Pierwszym warunkiem musi być to, że wybrany element nie jest grupą (w tym celu należy przejść do trybu „Warunek niestandardowy”).
Drugim warunkiem musi być to, że wybrany przedmiot jest usługą (jest to „Warunek prosty”):
W przyszłości przed realizacją żądania przekażemy odpowiednią wartość wyliczeniową do parametru „Typ nomenklatury”.
Przejdźmy do zakładki „Powiązania/Aliasy” i określmy, że widok pozycji katalogu będzie miał alias „Usługa”, a pole rejestru będzie miało alias „Przychody”:
Przejdźmy do zakładki „Zamówienie” i wskażmy, że wynik zapytania należy posortować malejąco według wartości pola „Przychody”.
W zakładce „Sumy” ustalamy, że mamy wyświetlić sumy ogólne i powinny one stanowić sumę wartości z pola „Przychody”:
Na karcie „Raport” usuń flagę „Użyj narzędzia do tworzenia raportów”.
Przejdźmy teraz do zakładki „Formularz wyjściowy”. Wskażmy, że parametry „Data zakończenia” i „Data rozpoczęcia” będą edytowane w formularzu w polach wejściowych typu „Data”. Natomiast dla parametru „Typ nomenklatury” usuniemy flagę edycyjną w postaci:
Kliknij OK". Platforma wygeneruje układ i formularz raportu. Otwórz moduł formularza i znajdź w nim procedurę „Ocena usługi”.
W tej procedurze w części ustawiania parametrów zapytania ustalimy wartość parametru „Typ nomenklatury” (poprawki zaznaczono pogrubioną czcionką):
| LEWE POŁĄCZENIE RejestrAkumulacja.Sprzedaż,Obrót(&Datapoczątkowa,
| &Termin ważności,)
| JAK SPRZEDAĆObrót
|ZAMÓW PRZEZ | PrzychodyW DÓŁ
|WYNIKI KWOTA (Przychody) WG | SĄ POSPOLITE";
RequestSetParameterC"Typ nomenklatury",
Przelewy. Rodzaje nomenklatury. Usługa);
Query.SetParameter("DataPoczątkowa",DataPoczątkowa); Request.SetParameterC"EndDate", EndDate);
Przyjrzyjmy się teraz tekstowi żądania wygenerowanemu przez konstruktora:
| SprNomenklatura.Reprezentacja AS Reprezentacja,
|SalesTurnover.RevenueTurnover AS Przychód
| Katalog.Nomenklatura AS RefNomenklatura
LEWE POŁĄCZENIE RegisterAccumulations.Sales.Turnover(&DataPoczątkowa,
| JAK SPRZEDAĆObrót
| Oprogramowanie SalesTurnover.Nomenclature = SprNomenclature.Link
| (RefNomenclature.ThisGroup = False) ORAZ
| SprNomenclature.Type of Nomenclature = &Typ nomenklatury
| ZAMÓW PRZEZ
| PrzychodyW DÓŁ
|WYNIKI KWOTA (Przychody) WG
Najpierw, jak zwykle, pojawia się część opisująca zgłoszenie, w której znajdują się konstrukcje, które są dla nas nowością.
Przy opisie źródeł żądań (po słowie kluczowym IZ) wykorzystano możliwość zdefiniowania kilku źródeł żądań:
| Katalog.Nomenklatura AS RefNomenklatura
|&Data zakończenia,)
| JAK SPRZEDAĆObrót
| Oprogramowanie SalesTurnover.Nomenclature = SprNomenclature.Link
W tym przypadku rekordy wybierane są z dwóch źródeł: „SprNomenklatura” i „SalesTurnover”, ze zdaniem kluczowym POŁĄCZENIE LEWE... PRZEZ opisuje sposób, w jaki rekordy z tych dwóch źródeł zostaną połączone.
POŁĄCZENIE LEWE oznacza, że wynik zapytania musi zawierać kombinacje rekordów z obu źródeł, które spełniają warunek określony po słowie kluczowym BY. Dodatkowo w wyniku zapytania muszą zostać uwzględnione także rekordy z pierwszego (wskazanego po lewej stronie słowa MIESZANINA)źródła, dla którego nie znaleziono żadnych rekordów spełniających warunek z drugiego źródła.
W opisie pierwszego źródła i warunku połączenia nie jest dla nas niczym nowym, natomiast opisując drugie źródło korzystamy z możliwości ustawienia parametrów zapytania wirtualnej tabeli:
| RegisterAccumulations.Sales.Turnover(&Data początkowa, &Data końcowa,)
Pierwszy parametr oznacza początek okresu obliczania sum, drugi oznacza koniec okresu. W rezultacie tabela źródłowa będzie zawierała jedynie obroty obliczone w przenoszonym okresie. Tutaj należy zawsze pamiętać, że jeśli jako te parametry przekażemy datę (a w naszym przypadku tak będzie), to data zawiera także czas z dokładnością do sekundy.
Jeżeli z góry wiadomo, że użytkownik nie będzie zainteresowany wynikami raportu w okresach określonych z dokładnością do sekund, wówczas należy uwzględnić następującą cechę: domyślnie czas w dacie ustawiony jest na 00 :00:00. Dlatego jeśli nie podejmiesz specjalnych działań, okaże się, że gdy użytkownik ustawi okres raportowania od 01.03.2004 do 31.03.2004, sumy rejestrów będą liczone od początku dnia 01/03/ 2004 00:00:00 do początku dnia 31.03.2004 00:00:00. Tym samym dane za 31 dzień, inny niż początek dnia, nie zostaną uwzględnione w kalkulacji, co bardzo zaskoczy użytkownika.
Aby wyeliminować tę sytuację, należy zrobić dwie rzeczy.
Po pierwsze, w formularzu raportu ogranicz możliwość wprowadzenia przez użytkownika daty początkowej i końcowej, ustawiając kompozycję dat dla odpowiednich pól wejściowych jako „Data”:
Ustalmy skład daty...
Po drugie, przekazując parametry, skorzystaj z wbudowanej funkcji Koniec dnia(). W tym celu wróć do modułu formularza raportu i dokonaj niezbędnych zmian (dodatki zaznaczono pogrubioną czcionką):
ProceduraFormActionsRatingServicesGenerate(Button) //((CONSTRUCTOR_WEEKEND_FORM_PROCEDURE_CALL(RatingServices) //Ten fragment został zbudowany przez konstruktora. // Ponowne użycie konstruktora // zmiany wprowadzone ręcznie zostaną utracone!!!
TabDoc = FormElements.TableField;
//))CONSTRUCTOR_OUTPUT_FORM_CALL_PROCEDURE
Współ. procedury sieciowe
Kontynuujmy analizę tekstu żądania. W ramach opisu zapytania istnieje jeszcze jedna, dla nas nowa konstrukcja - ustawienie warunków selekcji danych z tabel źródłowych:
| SprNomenklatura.Reprezentacja AS Reprezentacja,
| SalesTurnover.RevenueTurnover AS Przychód
| Katalog.Nomenklatura AS RefNomenklatura
| LEWE POŁĄCZENIE RegisterAccumulations.Sales.Turnover(&DataPoczątkowa,
| &Termin ważności,
| JAK SPRZEDAĆObrót
| Software SalesTurnover.Nomenclature = SprNomenclature.Ssshka
| SprNomenclature.ThisGroup = Fałsz AND
| SprNomenclature.Type of Nomenclature = &Typ nomenklatury
Warunek wyboru jest zawsze poprzedzony słowem kluczowym GDZIE. Następnie opisano sam stan. Należy pamiętać, że pola tabel źródłowych, na których zastosowano warunek, mogą nie zostać uwzględnione na liście wyboru (jak w naszym przypadku). Dodatkowo w naszym warunku używany jest parametr zapytania „Typ nomenklatury”.
WYNIKI KWOTA (Przychody) PO
Zawsze zaczyna się od słowa kluczowego WYNIKI, po którym następuje opis sum, które będą widoczne w wyniku zapytania. Zaraz po słowie WYNIKI opisuje funkcje zagregowane, które należy obliczyć w wynikach. W naszym przypadku przeliczona zostanie kwota znajdująca się w polu „Przychody”. Po nim następuje słowo kluczowe PO, po którym opisane są grupy, w których należy obliczyć sumy. W naszym przypadku są one nieobecne i używane jest jedynie słowo kluczowe SĄ POSPOLITE, co oznacza, że sumy zostaną obliczone dla całej tabeli jako całości.
Skoro już zapoznaliśmy się z treścią żądania, uruchommy 1C:Enterprise w trybie debugowania i zobaczmy, jak działa nasz raport.
Ustalmy okres raportowania od 01.03.2004 do 30.04.2004. Wynik będzie wyglądał następująco:
Zmieńmy teraz datę końcową na 31.03.2004 i upewnijmy się, że w raporcie uwzględnione są dane za 31 marca:
