Podmínka ve virtuální tabulce 1c. Tlačítko „Dotaz“ v návrháři dotazů

Při organizování vzorků v reálných problémech je v naprosté většině případů výběr dat organizován podle určitých kritérií.

V případě, že se výběr provádí ze skutečného stolu, nevznikají žádné potíže. Údaje jsou zpracovávány naprosto triviálně:

V případě, kdy je zdrojem v dotazu virtuální tabulka, se situace poněkud zkomplikuje.


Dotazovací jazyk vám umožňuje uložit podmínku na výběr z virtuálních tabulek dvěma způsoby: v klauzuli WHERE a pomocí parametrů virtuální tabulky. Obě metody povedou ke stejnému výsledku (s výjimkou některých specifických případů), ale přesto nejsou zdaleka ekvivalentní.

Již víme, že virtuální tabulky se nazývají virtuální, protože ve skutečnosti nejsou v databázi. Vznikají až v okamžiku, kdy je na ně vznesena žádost. Přesto je pro nás (tedy pro ty, kteří dotaz píší) pohodlné považovat virtuální tabulky za skutečné. Co se stane v systému 1C Enterprise 8, když dotaz, který jsme zkompilovali, stále přistupuje k virtuální tabulce?

V prvním kroku systém sestaví virtuální stůl. Ve druhém kroku budou z výsledné tabulky vybrány záznamy, které splňují podmínku uvedenou v klauzuli WHERE:
Je jasně vidět, že konečný vzorek nebude obsahovat všechny záznamy z virtuální tabulky (a tedy z databáze), ale pouze ty, které splňují danou podmínku. A zbývající záznamy budou z výsledku jednoduše vyloučeny.

Systém tak nebude dělat jen zbytečnou práci, ale dvojnásobnou zbytečnou práci! Nejprve se vynaloží prostředky na vytvoření virtuální tabulky založené na nepotřebných datech (na obrázku jsou označeny jako „datové oblasti A a B“) a poté se bude pracovat na filtrování těchto dat z konečného výsledku.

Je možné okamžitě, ve fázi konstrukce virtuální tabulky, přestat používat nepotřebná data? Ukazuje se, že je to možné. Přesně k tomu jsou určeny parametry virtuální tabulky:

Parametrizací virtuální tabulky okamžitě omezíme množství dat, která budou dotazem zpracována.

Jaký je rozdíl mezi hodnotami parametru virtuální tabulky "Metoda přidání"?
Když je metoda sčítání nastavena na „pohyby“, vrátí se pouze ta období, ve kterých byly pohyby. Když je nastaveno "Pohyby a hranice období", pak se k výše uvedeným pohybům přidají 2 záznamy: pohyby na začátku a na konci období specifikovaného v parametrech VT. Pole „Registrátor“ bude pro tyto 2 záznamy prázdné.

Informace převzaté z webu

Dotazovací jazyk v 1C 8 je zjednodušeným analogem známého „strukturovaného programovacího jazyka“ (jak se častěji nazývá SQL). Ale v 1C se používá pouze pro čtení dat, ke změně dat se používá objektový datový model.

Dalším zajímavým rozdílem je ruská syntaxe. I když ve skutečnosti můžete použít konstrukce v anglickém jazyce.

Příklad požadavku:

VYBRAT
Banks.Name,
Banky.Účet
Z
Adresář.Banky JAK Banky

Tento požadavek nám umožní zobrazit informace o jménu a korespondenčním účtu všech bank existujících v databázi.

Dotazovací jazyk je nejjednodušší a účinná metoda získávání informací. Jak je vidět z příkladu výše, v dotazovacím jazyce je potřeba používat názvy metadat (jedná se o seznam systémových objektů, které tvoří konfiguraci, tj. adresáře, dokumenty, registry atd.).

Popis konstrukcí dotazovacího jazyka

Struktura dotazu

Pro získání dat stačí použít konstrukce „SELECT“ a „FROM“. Nejjednodušší požadavek vypadá takto:

SELECT * FROM Directories.Nomenklatura

Kde „*“ znamená výběr všech polí tabulky a Directories.Nomenclature – název tabulky v databázi.

Podívejme se na složitější a obecnější příklad:

VYBRAT
<ИмяПоля1>JAK<ПредставлениеПоля1>,
Součet(<ИмяПоля2>) JAK<ПредставлениеПоля2>
Z
<ИмяТаблицы1>JAK<ПредставлениеТаблицы1>
<ТипСоединения>SLOUČENINA<ИмяТаблицы2>JAK<ПредставлениеТаблицы2>
PODLE<УсловиеСоединениеТаблиц>

KDE
<УсловиеОтбораДанных>

SKUPINA VYTVOŘENÁ
<ИмяПоля1>

SEŘAZENO PODLE
<ИмяПоля1>

VÝSLEDEK
<ИмяПоля2>
PODLE
<ИмяПоля1>

V tento požadavek vybereme data polí „FieldName1“ a „FieldName1“ z tabulek „TableName1“ a „TableName“, k polím přiřadíme synonyma pomocí operátoru „HOW“ a propojíme je pomocí určité podmínky „TableConnectionCondition“.

Z přijatých dat vybereme pouze data, která splňují podmínku z „KDE“ „Podmínka výběru dat.“ Dále seskupíme požadavek podle pole „Název pole1“, přičemž sečteme „Název pole2“. Pro pole vytvoříme součty „Název pole1“ a poslední pole „Název pole2“.

Posledním krokem je seřadit požadavek pomocí konstrukce ORDER BY.

Obecné návrhy

Podívejme se na obecné struktury dotazovacího jazyka 1C 8.2.

PRVNÍn

Používáním tohoto operátora můžete získat n počet prvních záznamů. Pořadí záznamů je určeno pořadím v dotazu.

VYBERTE PRVNÍCH 100
Banks.Name,
Banky Kód AS BIC
Z
Adresář.Banky JAK Banky
SEŘAZENO PODLE
Banky.Jméno

Požadavek obdrží prvních 100 položek z adresáře „Banky“ seřazených abecedně.

POVOLENO

Tato konstrukce je relevantní pro práci s mechanismem. Podstatou mechanismu je omezit čtení (a další akce) na uživatele pro konkrétní záznamy v databázové tabulce, a ne pro tabulku jako celek.

Pokud se uživatel pokusí pomocí dotazu přečíst záznamy, které jsou pro něj nepřístupné, zobrazí se mu chybové hlášení. Abyste tomu zabránili, měli byste použít konstrukci „ALLOWED“, tj. požadavek bude číst pouze záznamy, které jsou k němu povoleny.

VYBRAT POVOLENO
Úložiště dalších informací. Odkaz
Z
Adresář.Úložiště dalších informací

ROZLIČNÝ

Použití „DIFFERENT“ zabrání duplicitním řádkům ve vstupu do výsledku dotazu 1C. Duplikace znamená, že všechna pole požadavku se shodují.

VYBERTE PRVNÍCH 100
Banks.Name,
Banky Kód AS BIC
Z
Adresář.Banky JAK Banky

Prázdná tabulka

Tato konstrukce se pro kombinování dotazů používá velmi zřídka. Při připojování možná budete muset zadat prázdnou vnořenou tabulku v jedné z tabulek. Operátor „EmptyTable“ je k tomu jako stvořený.

Příklad z nápovědy 1C 8:

SELECT Link.Number, EMPTY TABLE.(No., Item, Quantity) AS Složení
FROM Document.Expense Faktura
KOMBINOVAT VŠECHNO
SELECT Link.Number, Contents. (LineNumber, Product, Quantity)
FROM Document.Invoice Document.Invoice.Composition.*

ISNULL

Velmi užitečná funkce, která vám umožní vyhnout se mnoha chybám. YesNULL() umožňuje nahradit hodnotu NULL požadovanou. Velmi často se používá při kontrole přítomnosti hodnoty ve spojených tabulkách, například:

VYBRAT
Odkaz na nomenklaturu,
IsNULL(Item Remaining.QuantityRemaining,0) AS QuantityRemaining
Z


Lze použít i jinak. Pokud například pro každý řádek není známo, ve které tabulce hodnota existuje:

ISNULL(InvoiceReceived.Date; InvoiceIssued.Date)

HOW je operátor, který nám umožňuje přiřadit název (synonymum) tabulce nebo poli. Příklad použití jsme viděli výše.

Tyto konstrukce jsou velmi podobné – umožňují získat řetězcovou reprezentaci požadované hodnoty. Jediný rozdíl je v tom, že REPRESENTATION převádí libovolné hodnoty na typ řetězce a REPRESENTATIONLINKS jsou pouze referenční. REFERENČNÍ REPREZENTACE se doporučuje používat v dotazech na skládání dat pro optimalizaci, pokud ovšem není plánováno použití referenčního datového pole ve výběrech.

VYBRAT
View(Link), //řetězec, například „Předběžná zpráva č. 123 ze dne 10.10.2015
Zobrazit (DeletionMark) AS DeleteMarkText, //string, „Ano“ nebo „Ne“
ViewReferences(DeletionMark) AS DeleteMarkBoolean //boolean, True or False
Z
Document.Advance Report

VYJÁDŘIT

Express umožňuje převádět hodnoty polí na správný typ data. Hodnotu můžete převést buď na primitivní typ, nebo na typ odkazu.

Express pro referenční typ se používá k omezení požadovaných datových typů v polích komplexního typu, často používaný k optimalizaci výkonu systému. Příklad:

EXPRESS(TableCost.Subconto1 AS Directory.Cost Items).Typ aktivity pro daňové náklady

U primitivních typů se tato funkce často používá k omezení počtu znaků v polích neomezené délky (s takovými poli nelze srovnávat). Aby nedošlo k chybě" Neplatné parametry v operaci porovnání. Nelze porovnávat obory
neomezená délka a pole nekompatibilních typů", musíte tato pole vyjádřit následovně:

EXPRESS(Komentář JAKO řádek(150))

DIFFERENCEDATE

Získejte 267 videolekcí na 1C zdarma:

Příklad použití IS NULL v požadavku 1C:

VYBRAT Z
Ref
LEVÉ PŘIPOJENÍ RegisterAkumulace.Produktyveskladech.Zbývající JAKO Zbývající produkt
Nomenclature softwaruRef.Link = Nomenklatura pro prodané zbožíCommitteesRemains
KDE NENÍ Zbývající produkty Množství Zbývající je NULL

Datový typ v dotazu lze určit následovně: pomocí funkcí TYPE() a VALUETYPE() nebo pomocí logický operátor ODKAZ. Obě funkce jsou podobné.

Předdefinované hodnoty

Kromě použití předávaných parametrů v dotazech v dotazovacím jazyce 1C můžete použít předdefinované hodnoty nebo . Například převody, předdefinované adresáře, účtové osnovy atd. K tomu se používá konstrukce „Value()“.

Příklad použití:

WHERE Nomenclature.Type of Nomenclature = Value(Directory.Types of Nomenclature.Product)

WHERE Protistrany. Typ kontaktních informací = Hodnota (výčet. Typy kontaktních informací. Telefon)

KDE Zůstatky na účtu. Účetní účet = Hodnota (Účtový diagram. Zisk. ZiskZtráta)

Spojení

Existují 4 typy připojení: VLEVO, ODJET, ŽE JO, KOMPLETNÍ, VNITŘNÍ.

LEVÉ a PRAVÉ PŘIPOJENÍ

Spojení se používají k propojení dvou tabulek na základě konkrétní podmínky. Funkce kdy PŘIPOJIT SE VLEVO spočívá v tom, že vezmeme první zadanou tabulku celou a podmíněně svážeme druhou tabulku. Pole druhé tabulky, která nemohla být svázána podmínkou, jsou vyplněna hodnotou NULA.

Například:

Vrátí celou tabulku Protistran a pole „Banka“ vyplní pouze v těch místech, kde bude splněna podmínka „Protistrany.Jméno = Banky.Jméno“. Není-li podmínka splněna, pole Banka bude nastaveno na NULA.

RIGHT JOIN v jazyce 1C naprosto podobný LEVÉ připojení, s výjimkou jednoho rozdílu - v PRÁVO PŘIPOJENÍ„Hlavní“ tabulka je druhá, nikoli první.

PLNÉ PŘIPOJENÍ

PLNÉ PŘIPOJENÍ se od levé a pravé liší tím, že zobrazuje všechny záznamy ze dvou tabulek a spojuje pouze ty, které dokáže spojit podle podmínky.

Například:

Z

PLNÉ PŘIPOJENÍ
Adresář.Banky JAK Banky

PODLE

Dotazovací jazyk vrátí obě tabulky úplně, pouze pokud je splněna podmínka pro spojení záznamů. Na rozdíl od spojení vlevo/vpravo je možné, aby se NULL objevila ve dvou polích.

VNITŘNÍ SPOJENÍ

VNITŘNÍ SPOJENÍ se od plného liší tím, že zobrazuje pouze ty záznamy, které bylo možné podle dané podmínky propojit.

Například:

Z
Adresář Protistrany AS klienti

VNITŘNÍ SPOJENÍ
Adresář.Banky JAK Banky

PODLE
Clients.Name = Banks.Name

Tento dotaz vrátí pouze řádky, ve kterých mají banka a protistrana stejný název.

Asociace

Konstrukce JOIN a JOIN ALL kombinují dva výsledky do jednoho. Tito. výsledek provedení dvou se „sloučí“ do jednoho, společného.

To znamená, že systém funguje úplně stejně jako běžné, pouze pro dočasnou tabulku.

Jak používat INDEX BY

Je však třeba vzít v úvahu jeden bod. Vytvoření indexu na dočasné tabulce také nějakou dobu trvá. Proto je vhodné použít konstrukci „ “ pouze v případě, že je jisté, že v dočasné tabulce bude více než 1-2 záznamy. V opačném případě může být efekt opačný – výkon indexovaných polí nekompenzuje čas potřebný k vytvoření indexu.

VYBRAT
Kurzy měn Nejnovější průřez Měna AS Měna,
Kurzy měn Nejnovější průřez.
Kurzy měn PUT
Z
Informace Registrovat. Kurzy měn.Poslední řez (&období,) AS Kurzy měnPoslední řez
INDEX BY
Měna
;
VYBRAT
Ceny Nomenklatura.Nomenklatura,
Ceny Nomenklatury. Cena,
Ceny Nomenklatury. Měna,
Kurzy měn. Kurz
Z
Registr informací.Nomenklatura Ceny.Poslední řez (&období,
Nomenklatura B (&Nomenklatura) A PriceType = &PriceType) AS Cenová nomenklatura
LEFT JOIN kursy měn JAKO kursy měn
Ceny softwaru Nomenclatures.Currency = Kurzy měn.Měna

Seskupování

Dotazovací jazyk 1C vám umožňuje používat speciální agregační funkce při seskupování výsledků dotazu. Seskupování lze také použít bez agregačních funkcí k „eliminaci“ duplicit.

Existují následující funkce:

Množství, Množství, Počet různých, Maximum, Minimum, Průměr.

Příklad č. 1:

VYBRAT
Prodej zboží a služeb Zboží. Nomenklatura,
SUM(Prodej zbožíSlužbyZboží.Množství) AS Množství,
SUM(Sales of GoodsServicesGoods.Amount) AS Částka
Z

SKUPINA VYTVOŘENÁ
Prodej zboží a služeb Zboží Nomenklatura

Požadavek obdrží všechny řádky se zbožím a sumarizuje je podle množství a množství podle položky.

Příklad č. 2

VYBRAT
Banks.Code,
MNOŽSTVÍ (RŮZNÉ Banky. Odkaz) JAKO Počet duplikátů
Z
Adresář.Banky JAK Banky
SKUPINA VYTVOŘENÁ
Banks.Code

Tento příklad zobrazí seznam BIC v adresáři „Banks“ a ukáže, kolik duplikátů pro každý z nich existuje.

Výsledek

Výsledky – způsob, jak získat data ze systému s hierarchická struktura. Agregační funkce lze použít pro souhrnná pole, stejně jako pro seskupení.

Jedním z nejoblíbenějších způsobů využití výsledků v praxi je dávkový odpis zboží.

VYBRAT




Z
Dokument Prodej zboží a služeb zboží JAK na prodej zboží a služeb zboží
SEŘAZENO PODLE

VÝSLEDEK
SUM(množství),
SOUČET (Součet)
PODLE
Nomenklatura

Výsledek dotazu bude následující hierarchický:

Obecné výsledky

Pokud potřebujete získat součty pro všechny „součty“, použijte operátor „OBECNÉ“.

VYBRAT
Prodej zboží a služeb Zboží Nomenklatura AS Nomenklatura,
Prodej zboží a služeb Zboží Odkaz AS Dokument,
Prodej zboží a služeb Zboží Množství AS Množství,
Prodej zboží a služeb Zboží Částka AS Částka
Z
Dokument Prodej zboží a služeb zboží JAK na prodej zboží a služeb zboží
SEŘAZENO PODLE
Prodej zboží a služeb Zboží. Odkaz. Datum
VÝSLEDEK
SUM(množství),
SOUČET (Součet)
PODLE
JSOU BĚŽNÉ,
Nomenklatura

V důsledku provedení požadavku získáme následující výsledek:

Ve které 1 úrovni seskupení je agregace všech potřebných polí.

Zařizování

Operátor ORDER BY se používá k řazení výsledku dotazu.

Řazení pro primitivní typy (řetězec, číslo, boolean) se řídí obvyklými pravidly. U polí typu odkazu dochází k řazení podle vnitřní reprezentace odkazu (jedinečného identifikátoru), spíše než podle kódu nebo podle reprezentace odkazu.

VYBRAT

Z
Directory.Nomenclature AS Nomenklatura
SEŘAZENO PODLE
název

Požadavek zobrazí seznam jmen v adresáři nomenklatur seřazený abecedně.

Automatická objednávka

Výsledkem dotazu bez řazení je chaoticky prezentovaná sada řádků. Vývojáři platformy 1C nezaručují, že při provádění identických dotazů budou řádky vydávány ve stejném pořadí.

Pokud potřebujete zobrazit záznamy tabulky v konstantním pořadí, musíte použít konstrukci Auto-Order.

VYBRAT
Nomenklatura.Name AS Jméno
Z
Directory.Nomenclature AS Nomenklatura
AUTO OBJEDNÁVKA

Virtuální stoly

Virtuální tabulky v 1C jsou jedinečnou funkcí dotazovacího jazyka 1C, která se nenachází v jiných podobných syntaxích. Virtuální stůl - rychlý způsob získávání informací o profilu z registrů.

Každý typ registru má svou vlastní sadu virtuálních tabulek, které se mohou lišit v závislosti na nastavení registru.

  • řez prvního;
  • řez posledně jmenovaného.
  • zbytky;
  • revoluce;
  • zůstatky a obrat.
  • pohyby z podkonta;
  • revoluce;
  • rychlost Dt Kt;
  • zbytky;
  • zůstatky a obrat
  • subconto.
  • základna;
  • grafová data;
  • skutečnou dobu platnosti.

Pro vývojáře řešení jsou data přebírána z jedné (virtuální) tabulky, ale ve skutečnosti platforma 1C bere z mnoha tabulek a převádí je do požadované podoby.

VYBRAT
Produkty ve skladech Zbytky a obrat. Nomenklatura,
ProductsInWarehousesRemainingAndTurnover.QuantityInitialRemaining,
ProductsInWarehousesRemainsAndTurnover.QuantityObrat,
ZbožíInWarehousesRemainsAndTurnover.QuantityIncoming,
ProductsIn WarehousesRemainsAndTurnover.QuantitySpotřeba,
ProductsInWarehousesRemainingsAndTurnover.QuantityFinalRemaining
Z
RegisterAccumulations.GoodsInWarehouses.RemainsAndTurnover AS GoodsInWarehousesRemainsAndTurnover

Tento dotaz umožňuje rychle získat velké množství dat.

Možnosti virtuálního stolu

Velmi důležitým aspektem práce s virtuálními tabulkami je použití parametrů. Parametry virtuální tabulky jsou specializované parametry pro výběr a konfiguraci.

U takových tabulek se považuje za nesprávné použít výběr v konstrukci „WHERE“. Kromě toho, že se dotaz stane neoptimálním, je možné přijímat nesprávná data.

Příklad použití těchto parametrů:

Evidence kumulací. Zboží ve skladech. Zůstatky a obraty (& Začátek období, & Konec období, Měsíc, pohyby a hranice období, Číselník = & Povinné názvosloví)

Algoritmus pro virtuální tabulky

Například nejpoužívanější virtuální tabulka typu „Remains“ ukládá data ze dvou fyzických tabulek – zůstatky a pohyby.

Při použití virtuální tabulky systém provádí následující manipulace:

  1. V tabulce součtů získáme nejbližší vypočítanou hodnotu z hlediska data a měření.
  2. Částku z tabulky pohybu „přičteme“ k částce z tabulky součtů.


Takové jednoduché akce mohou výrazně zlepšit výkon systému jako celku.

Použití Tvůrce dotazů

Tvůrce dotazů– nástroj zabudovaný do systému 1C Enterprise, který výrazně usnadňuje vývoj databázových dotazů.

Tvůrce dotazů má poměrně jednoduché a intuitivní rozhraní. Přesto se podívejme na použití konstruktoru dotazu podrobněji.

Konstruktor textu dotazu se spouští z kontextové nabídky (pravé tlačítko myši) na požadovaném místě v kódu programu.

Popis konstruktoru požadavku 1C

Podívejme se na každou záložku návrháře podrobněji. Výjimkou je záložka Builder, která je tématem na jinou diskusi.

Karta Tabulky a pole

Tato karta určuje zdroj dat a pole, která je třeba v sestavě zobrazit. V podstatě jsou zde popsány konstrukce SELECT.. FROM.

Zdrojem může být fyzická databázová tabulka, virtuální tabulka registrů, dočasné tabulky, vnořené dotazy atd.

V kontextovém menu virtuálních tabulek můžete nastavit parametry virtuální tabulky:

Karta Připojení

Záložka slouží k popisu spojení několika tabulek a vytváří konstrukce se slovem SPOJENÍ.

Karta seskupení

Na této záložce systém umožňuje seskupit a shrnout požadovaná pole výsledku tabulky. Popisuje použití konstrukcí GROUP BY, SUM, MINIMUM, AVERAGE, MAXIMUM, QUANTITY, NUMBER OF RŮZNÉ.

Záložka Podmínky

Zodpovídá za vše, co přijde v textu požadavku po konstrukci WHERE, tedy za všechny podmínky kladené na přijatá data.

Karta Upřesnit

Tab dodatečně plný nejrůznějších parametrů, které jsou velmi důležité. Podívejme se na každou z vlastností.

Seskupování Výběr záznamů:

  • První n– parametr, který dotazu vrátí pouze N záznamů (operátor FIRST)
  • Žádné duplikáty– zajišťuje jedinečnost přijatých záznamů (JINÝ operátor)
  • Povoleno– umožňuje vybrat pouze ty záznamy, které vám systém umožňuje vybrat s přihlédnutím k (POVOLENÁ konstrukce)

Seskupování Typ požadavku určuje, jaký typ požadavku bude: načtení dat, vytvoření dočasné tabulky nebo zničení dočasné tabulky.

Dole je vlajka Uzamknout přijatá data pro pozdější úpravu. Umožňuje povolit možnost nastavení uzamčení dat, které zajišťuje bezpečnost dat od okamžiku jejich načtení až po jejich změnu (relevantní pouze pro Automatický režim stavědla, provedení NA ZMĚNU).

Karta spojení/aliasy

Na této kartě návrháře dotazů můžete nastavit možnost spojování různých tabulek a aliasů (konstrukt HOW). Tabulky jsou vyznačeny na levé straně. Pokud nastavíte příznaky naproti tabulce, použije se konstrukce UNITE, jinak - UNITE ALL (rozdíly mezi oběma metodami). Na pravé straně je uvedena korespondence polí v různých tabulkách, pokud korespondence není uvedena, dotaz vrátí hodnotu NULL.

Záložka Objednávka

Toto určuje pořadí, ve kterém jsou hodnoty seřazeny (ORDER BY) - sestupně (DESC) nebo vzestupně (ASC).

Je zde také zajímavá vlajka - Automatická objednávka(v poptávce - AUTO OBJEDNÁVKA). Ve výchozím nastavení systém 1C zobrazuje data v „chaotickém“ pořadí. Pokud nastavíte tento příznak, systém seřadí data podle interních dat.

Karta Dávkový dotaz

Na kartě Návrhář dotazů můžete vytvořit nové a také ji použít jako navigaci. V textu požadavku jsou pakety odděleny symbolem „;“ (čárkou).

Tlačítko „Dotaz“ v návrháři dotazů

V levém dolním rohu návrháře požadavku je tlačítko Požadavek, pomocí kterého můžete kdykoli zobrazit text požadavku:

V tomto okně můžete provést úpravy požadavku a provést jej.


Pomocí konzoly dotazů

Query Console je jednoduchý a pohodlný způsob, jak ladit složité dotazy a rychle získávat informace. V tomto článku se pokusím popsat, jak používat Query Console a poskytnout odkaz na stažení Query Console.

Pojďme se na tento nástroj podívat blíže.

Stáhněte si konzoli dotazů 1C

Za prvé, abyste mohli začít pracovat s konzolí dotazů, musíte ji odněkud stáhnout. Léčba se obvykle dělí na dva typy - kontrolované formy a pravidelné (nebo někdy nazývané 8.1 a 8.2/8.3).

Zkusila jsem tyto dva druhy zkombinovat v jednom ošetření – in požadovaný režim operace, otevře se požadovaný formulář (ve spravovaném režimu konzola funguje pouze v tlustém režimu).

Popis konzole dotazu 1C

Začněme se podívat na konzolu dotazů s popisem hlavního panelu zpracování:

V záhlaví konzoly dotazu můžete vidět čas provedení posledního dotazu s přesností na milisekundy, což vám umožňuje porovnávat různé návrhy z hlediska výkonu.

První skupina tlačítek na panelu příkazů je zodpovědná za ukládání aktuálních dotazů do externího souboru. To je velmi pohodlné, vždy se můžete vrátit k psaní složitého požadavku. Nebo si například uložte seznam typických příkladů určitých vzorů.

Vlevo v poli „Požadavek“ můžete vytvářet nové požadavky a ukládat je do stromové struktury. Druhá skupina tlačítek je zodpovědná za správu seznamu požadavků. Pomocí něj můžete vytvořit, kopírovat, mazat, přesouvat požadavek.

  • Vykonatžádost– jednoduché provedení a výsledky
  • Spustit balíček– umožňuje zobrazit všechny přechodné dotazy v dávce dotazů
  • Zobrazení dočasných tabulek– umožňuje zobrazit výsledky, které dočasné dotazy vracejí v tabulce

Parametry požadavku:

Umožňuje nastavit aktuální parametry požadavku.

V okně parametrů dotazu je zajímavé následující:

  • Knoflík Získejte z žádosti automaticky najde všechny parametry v požadavku pro pohodlí vývojáře.
  • Vlajka Společné parametry pro všechny požadavky– při jeho zpracování nedojde k vymazání parametrů při přechodu z požadavku na požadavek v obecném seznamu požadavků.

Nastavte parametr se seznamem hodnot Je to velmi jednoduché, stačí při výběru hodnoty parametru kliknout na tlačítko smazat hodnotu (křížek), systém vás vyzve k výběru datového typu, kde je třeba vybrat „Value List“:

V horním panelu je také tlačítko pro vyvolání nastavení konzoly dotazu:

Zde můžete zadat parametry pro automatické ukládání dotazů a parametry provádění dotazů.

Text požadavku se zadává do pole požadavku konzoly. To lze provést jednoduchým zadáním testu dotazu nebo zavoláním speciálního nástroje – návrháře dotazů.

Návrhář dotazů 1C 8 se vyvolá z kontextové nabídky (pravé tlačítko myši), když kliknete na vstupní pole:

Také v této nabídce jsou takové užitečné funkce, jako je vymazání nebo přidání zalomení řádků („|“) k požadavku nebo získání kódu požadavku v této pohodlné formě:

Žádost = Nová žádost;
Request.Text = ”
|VYBRAT
| Měny. Odkaz
|OD
| Adresář.Currencies AS Currencies“;
RequestResult = Request.Execute();

Spodní pole konzoly dotazu zobrazuje pole výsledku dotazu, proto bylo toto zpracování vytvořeno:



Také dotazovací konzole kromě seznamu může zobrazovat data ve formě stromu - pro dotazy obsahující součty.

Optimalizace dotazu

Jedním z nejdůležitějších bodů při zvyšování produktivity 1C enterprise 8.3 je optimalizacežádosti. Tento bod je také velmi důležitý, kdy absolvování certifikace. Níže budeme hovořit o typické důvody ne optimální provoz dotazů a optimalizačních metod.

Výběry ve virtuální tabulce pomocí konstrukce WHERE

Na detaily virtuální tabulky je nutné aplikovat filtry pouze prostřednictvím parametrů VT. V žádném případě nepoužívejte pro výběr ve virtuální tabulce konstrukci WHERE, to je z hlediska optimalizace závažná chyba. V případě výběru pomocí WHERE totiž systém přijme VŠECHNY záznamy a teprve poté vybere potřebné.

ŽE JO:

VYBRAT

Z
Registr kumulací. Vzájemné vyrovnání s účastníky organizací. Zůstatky (
,
Organizace = &Organizace
AND Jednotlivec = &Jednotlivec) JAK Vzájemné vyrovnání s účastníky organizací zůstatky

ŠPATNĚ:

VYBRAT
Vzájemné vyrovnání zůstatků s účastníky organizací Částka Zůstatek
Z
Registr kumulací Vzájemná vypořádání s účastníky organizací Zůstatky (,) JAK Vzájemná vyrovnání s účastníky organizací Zůstatky
KDE
Vzájemné vyrovnání zůstatků s účastníky organizací Organizace = & Organizace
AND Vzájemné vyrovnání s účastníky zůstatků organizací Individuální = &Jednotlivec

Získání hodnoty pole komplexního typu pomocí tečky

Při příjmu dat komplexního typu v dotazu přes tečku se systém spojí levým spojením přesně tolik tabulek, kolik je možných typů v poli komplexního typu.

Například pro optimalizaci je vysoce nežádoucí přístup do pole záznamu registru – registrátor. Registrátor má složený datový typ, mezi nimiž jsou všechny možné typy dokumentů, které mohou zapisovat data do registru.

ŠPATNĚ:

VYBRAT
Record Set.Recorder.Date,
RecordSet.Quantity
Z
RegisterAccumulations.ProductsOrganizations AS SetRecords

To znamená, že ve skutečnosti takový dotaz nezpřístupní jednu tabulku, ale 22 databázových tabulek (tento registr má 21 typů registrátorů).

ŽE JO:

VYBRAT
VÝBĚR
WHEN ProductsOrg.Registrar LINK Document.Sales of Products and Services
PAK EXPRESNÍ (ProductsOrganization. Registrator AS Document. Sales of GoodsServices).Datum
WHEN GoodsOrg.Registrar LINK Document.Receipt of GoodsServices
PAK EXPRESNÍ (GoodsOrg.Registrar AS Document.Receipt of GoodsServices).Datum
KONEC JAKO DATUM,
ProduktyOrg. Množství
Z
RegisterAccumulations.GoodsOrganizations AS GoodsOrganizations

Nebo druhá možnost je přidat takové informace do detailů, například v našem případě přidání data.

ŽE JO:

VYBRAT
ProductsOrganizations.Date,
Produkty Organizace. Množství
Z
Registr kumulací Zboží organizací AS Zboží organizací

Poddotazy ve stavu spojení

Pro optimalizaci je nepřípustné používat poddotazy v podmínkách spojení, což výrazně zpomaluje dotaz. V takových případech je vhodné použít VT. Chcete-li se připojit, musíte použít pouze metadata a objekty VT, které jste předtím indexovali podle polí připojení.

ŠPATNĚ:

VYBRAT …

PŘIPOJIT SE VLEVO (
SELECT FROM RegisterInformation.Limits
KDE…
SKUPINA VYTVOŘENÁ...
) OD…

ŽE JO:

VYBRAT …
Limity PUT
FROM Information Register.Limits
KDE…
SKUPINA VYTVOŘENÁ...
INDEX BY...;

VYBRAT …
Z dokumentu Prodej zboží a služeb
Limity LEVÉHO PŘIPOJENÍ
BY …;

Spojení záznamů s virtuálními tabulkami

Jsou situace, kdy při propojení virtuálního stolu s ostatními systém nefunguje optimálně. V tomto případě pro optimalizaci výkonu dotazu můžete zkusit umístit virtuální tabulku do dočasné tabulky a nezapomenout indexovat spojená pole v dotazu na dočasnou tabulku. To je způsobeno skutečností, že VT jsou často obsaženy v několika fyzických tabulkách DBMS; v důsledku toho je zkompilován poddotaz, který je vybere, a problém se ukáže jako podobný předchozímu bodu.

Použití výběrů založených na neindexovaných polích

Jednou z nejčastějších chyb při psaní dotazů je používání podmínek na neindexovaných polích, což je v rozporu pravidla optimalizace dotazů. DBMS nemůže provést dotaz optimálně, pokud dotaz obsahuje výběr na neindexovatelných polích. Pokud vezmete dočasnou tabulku, musíte také indexovat pole připojení.

Pro každou podmínku musí existovat vhodný index. Vhodný index je takový, který splňuje následující požadavky:

  1. Index obsahuje všechna pole uvedená v podmínce.
  2. Tato pole jsou na samém začátku indexu.
  3. Tyto výběry jsou po sobě jdoucí, to znamená, že hodnoty, které nejsou zahrnuty do podmínky dotazu, mezi nimi nejsou „zaklíněné“.

Pokud DBMS nevybere správné indexy, bude naskenována celá tabulka – to bude mít velmi negativní dopad na výkon a může vést k dlouhodobému zablokování celé sady záznamů.

Použití logického OR v podmínkách

To je vše, tento článek se zabýval základními aspekty optimalizace dotazů, které by měl znát každý odborník na 1C.

Velmi užitečný bezplatný videokurz o vývoji a optimalizaci dotazů, Vřele doporučuji pro začátečníky a další!

Pokud je pro vás moje publikace užitečná, nezapomeňte ji dát plus :-)

Zde je rubrikátor pro všechny úkoly ve sbírce(stránka obsahující odkazy na vlákna fóra pro každý úkol)
http://chistov.spb.ru/forum/16-969-1

No, nyní můj vývoj a poznámky, které jsem vytvořil během procesu přípravy.
Pokusím se s oběma výše zmíněnými opakovat co nejméně poslední publikace.

Takže začneme:


Pokud to uděláte na dálku, měli byste mít na konci zkoušky na ploše dva objekty:

1. Konečná vykládka informační základna(soubor dt)
2. Vysvětlivka

Nemělo by tam být nic jiného, ​​žádné mezikopie atd.

Nezapomeňte napsat vysvětlující poznámku!
V případě nejasně formulovaného úkolu tam určitě napište, že jste zvolili přesně takovou a takovou možnost řešení.
Také na klíčových místech v kódu je lepší zanechat krátké komentáře, bez fanatismu, ale tam, kde může mít zkoušející otázky, je lepší psát.

Ale o tom budete informováni v pokynech, které si před zkouškou přečtete.
Jen je lepší vědět předem)


Použití znaku ampersand v dotazech.

Někdy je rychlejší psát z další klávesnice než přepínat rozložení tam a zpět, což šetří čas
& = Alt+38

*************************************************************************************************
Použití TimePoint() v dotazech

V dotazech do akumulačních a účetních registrů je nutné jako parametr virtuální tabulky (období) použít nikoli datum dokladu, ale parametr Okamžik, který je v kódu definován takto:

Okamžik = ? (Režim předání = Režim zaúčtování dokumentu. Provozní, Nedefinováno, Okamžik času());

*************************************************************************************************
Při generování pohybů dokladů registrem je na samém začátku procesu zpracování zaúčtování nutné vymazat pohyby aktuálního dokladu registrem.

Kód je:

Movement.RegisterName.Write = True; Movements.RegisterName.Clear();

Je možné, že během procesu bude nutné analyzovat záznamy z tohoto registru.
Aby při analýze aktuálních záznamů (starých, před změnou dokumentu) rozhodně nebyly zahrnuty do vzorku, můžete k daným dvěma řádkům přidat jeden řádek navíc:

Movement.RegisterName.Write();

Nebo při analýze záznamů explicitně označte hranici, která nezahrnuje časový bod aktuálního dokumentu.

Ale všude jsem jednoduše naznačil konstrukci těchto tří čar:

Movement.RegisterName.Write = True; Movements.RegisterName.Clear(); Movement.RegisterName.Write();

*************************************************************************************************
Existují dva způsoby blokování dat, výběr mezi nimi závisí na použité metodě - staré nebo nové:

1) Pravidelné řízené blokování, starý způsob zpracování dokumentů (objekt Blokování dat)

Nastavte, zda se zůstatky nejprve kontrolují a poté odepisují.
V případě, kdy potřebujeme mít nějaké informace z registru k vytvoření pohybu.

Příklad:

V dokladu - množství, v evidenci - množství a množství (náklad)
Z dokladu tedy známe množství zboží - kolik odepisujeme, ale náklady - ne.
Zjistíme to pouze z registru, ale abychom zajistili, že mezi okamžikem přijetí zůstatků a okamžikem zapsání pohybů registr nikdo nezmění, musíme registr uzamknout ještě před načtením zůstatků.
V tomto případě je tedy použit objekt Data Locking. A při jeho vytváření je správnější uvést, jakými rozměry blokujeme registr (například v našem případě - pouze položkou uvedenou v dokumentu) - aby nebyly zbytečné zámky a jiný uživatel mohl prodat další položka.


1. Nastavte zámek pomocí objektu Data Lock
2. Přečtěte si zbytek
3. Prověříme možnost odpisu
4. Vytváříme pohyby, např. odepisujeme zboží
5. Po zaúčtování dokladu je blokace automaticky odstraněna (blokace je platná v rámci zaúčtování a je automaticky odstraněna systémem). To znamená, že není třeba objekt speciálně odemykat.

2) Nová metodika zpracování dokumentů (pomocí vlastnosti LockForChange = True)

Používá se v případě, že nepotřebujeme informace z registrů k vytvoření pohybů a zda jsme se při odepisování nedostali do záporu, můžeme zkontrolovat, pokud se po zapsání podíváme na zůstatky v registru a zjistíme, že jsou záporné. . V tomto případě pochopíme, že jsme odepsali příliš mnoho a operaci odpisu zrušíme.

Příklad:
Uvažujme o operaci prodeje produktu.
V dokladu - množství, v evidenci - pouze množství
Z dokladu tedy známe množství zboží.
Sestavujeme pohyby s množstvím uvedeným v dokladu a evidujeme je. Dále čteme registr, podíváme se na zůstatky a analyzujeme, zda existují nějaké záporné. Pokud ano, zobrazte chybu a nastavte Odmítnutí = Pravda.

To znamená, že sekvence je taková:
1. Chcete-li procházet registrem, nastavte vlastnost BlockForChange = True
2. Vytváříme pohyby - odepisujte zboží
3. Zaznamenejte pohyby
4. Přečtěte si registr a ujistěte se, že v něm nejsou žádné záporné zůstatky. Pokud existuje, pak přebytek odepsali, pokud ne, pak je vše v pořádku.

V tomto případě tedy není potřeba uvádět, o jaké rozměry potřebujeme registr zablokovat.
Jednoduše nastavíme vlastnost BlockForChange na True předtím, než zaznamenáme naše pohyby, vytvoříme pohyby a zaznamenáme.
Systém sám zablokuje registr v době záznamu podle měření, která jsou potřebná, po analýze toho, co jsme zaznamenali.
Po dokončení bude blokování odstraněno.

Tato možnost (druhá) je jednodušší, nazývá se „nová metodika zpracování dokumentů“ a 1C ji doporučuje používat, pokud je to možné, a odečítá body, pokud je použita první možnost, ale v některých případech ji prostě nelze použít a první možnost s je použit objekt Data Locking (viz výše uvedený příklad).

Dále podotýkám, že bez ohledu na zvolenou metodu je nutné strojky před prací vyčistit (viz předchozí rada)

*************************************************************************************************
Blokování dat (způsob blokování č. 1 z výše uvedeného popisu)

Řízené zamykání je vyžadováno tam, kde jsou data čtena a pohyby jsou prováděny na základě těchto dat
Nejrychlejší způsob, jak získat spravovaný uzamykací kód, je zadat „Data Locking“, zavolat Syntax Assistant a jednoduše odtud zkopírovat vzorový kód. Pak jej jednoduše změňte na název vašeho registru a rozměry.

Vypadá to asi takto:

Lock = NewDataLock; Uzamykací prvek = Locking.Add("Registr akumulace.ZbožíVSkladech"); LockElement.Mode = DataLockMode.Exclusive; BlockingElement.DataSource = PM; Locking Element.UseFromDataSource("Nomenklatura", "Nomenklatura"); Lock.Lock();

*************************************************************************************************
Tabulkovou část dokumentů je lepší nazývat jednoduše „TC“

V 99 % dokumentů je pouze jedna tabulková část. Takový jednotný název tabulkové části Pomůže vám to ušetřit spoustu času, protože:
1) Velmi krátké - pište rychle
2) Totéž pro všechny dokumenty, při psaní kódu si nemusíte pamatovat, jak se tomu říká

*************************************************************************************************
Před načtením nebo nahráním do technické specifikace by měl být výsledek dotazu zkontrolován, zda není prázdný.

Obecně jsem ve všech úlohách používal vzorkování.

Vzorkování je pro systém z hlediska výkonu optimálnější, protože je „naostřeno“ pouze pro čtení dat (na rozdíl od TK).

Ale v každém případě je před metodou Select() lepší zkontrolovat výsledek dotazu na prázdnotu, tím se ještě sníží zátěž systému.

Výsledek = Query.Run(); If Not Result.Empty() Then Select = Result.Select(TravelQueryResult.ByGrouping); ... EndIf;

A v případě, že potřebujeme z požadavku získat pouze jednu hodnotu
(například pouze způsob odpisu v souladu s účetní politikou stanovenou pro tento rok):

Výsledek = Query.Run(); If Not Result.Empty() Then Select = Result.Select(); Selection.Next(); Metoda odpisu nákladů = Sample.Cost Write-Off Method; endIf;

*************************************************************************************************
Dokument "Operace" pro účetní úlohu

Pro účetní úkony je nutné vytvořit Provozní doklad.

Úplně u něj zakážeme účtování (ve vlastnostech „Zaúčtování = Odepřít“), označíme, že provádí pohyby v účetní evidenci, a přesuneme pohyby do formuláře.

*************************************************************************************************
Rychlé vyřízení dokumentů:

Musí být zahrnuta:
Provozně i účetní. musí být povoleno účtování dokladů (kromě dokladu „Provoz“, viz níže).

Musí být vypnutý:
v kalkulačních úlohách nemá smysl pro mzdový doklad.

U dokladu "Provoz" by mělo být účtování úplně zakázáno (ve vlastnostech dokladu "Zaúčtování = Zakázat"),
jelikož zapisuje, jednoduše zapisuje data přímo do registru při zápisu.

*************************************************************************************************
Podmínka ve formuláři žádosti "Buď specifikovaná nomenklatura nebo jakákoli, není-li uvedena"

V dotazech se setkáte s následujícím úkolem: například potřebujete vybrat dokumenty se zadanou nomenklaturou nebo všechny dokumenty, pokud nomenklatura není zadána.
Řeší se to následující podmínkou v samotné žádosti:

Nomenklatura = &Nomenklatura NEBO &Nomenklatura = Hodnota(Directory.Nomenclature.EmptyLink)

Ale bylo by optimálnější a správnější transformovat tento stav (díky yukon):


Request.Text = Request.Text + "WHERE Nomenklatura = &Nomenklatura";

endIf;

S příchodem objektového modelu dotazu v 8.3.5 bude možné přidat podmínku bezpečněji:

If ValueFilled(Nomenclature) Then
Query1.Selection.Add("Položka = &Nomenklatura");
Request.SetParameter("Nomenklatura", Nomenklatura);
endIf;

*************************************************************************************************
Spojování tabulek v dotazech:

Počet celkových záznamů nezávisí na tom, zda je zobrazeno pole spojené tabulky, závisí pouze na nakonfigurovaných vztazích.
To znamená, že pole připojené tabulky se nemusí zobrazit.

Pokud chcete připojit tabulku bez podmínek, pak na záložce podmínky jednoduše napište podmínku „PRAVDA“.
V tomto případě bude stůl přesně spojen.

*************************************************************************************************
Pomocí plánu typů charakteristik (PVC):

1. Použití jako mechanismus pro popis vlastností objektů.

1.1. Vyrábíme PVC. Budou to Typy charakteristik (například barva, velikost, max. rychlost atd.). V nastavení vyberte všechny možné typy charakteristických hodnot a případně vytvořte objekt z bodu 1.2 a také jej uveďte v nastavení.

1.2. Pro další hodnoty PVC vytvoříme podřízený adresář AdditionalValues ​​of Characteristics (nebo jednoduše Values ​​of Characteristics).
Uloží charakteristiky, pokud nejsou v existujících adresářích. Nemusíme jej vytvořit, pokud jsou všechny vlastnosti, které potřebujeme, v existujících adresářích, nebo tyto hodnoty mohou být reprezentovány elementárními datovými typy. V nastavení PVC určíme, že tento adresář bude použit pro další účely. charakteristické hodnoty.

1.3. Vytváříme informační registr, který vlastně spojuje tři objekty:
- Objekt, ke kterému připojíme mechanismus charakteristik
- Typové vlastnosti (typ PVC)
- Hodnota charakteristiky (typ - charakteristika, jedná se o nový typ, který se objevil v systému po vytvoření PVC
a popis všech možných datových typů, které může charakteristická hodnota nabývat).
V registru informací uvedeme, že Vlastníkem Charakteristické hodnoty je Typ charakteristiky (odkaz na parametr výběru), stejně jako typové spojení pro Charakteristickou hodnotu, opět z Typu Charakteristiky.

Další funkcí je, že pro každý vytvořený typ charakteristiky můžete určit typ hodnoty charakteristiky, pokud nepotřebujete všechny možné typy pro popis hodnoty této charakteristiky.

2. Použití PVC k vytvoření sub-conto mechanismu pro účetní registr .

2.1. Vytváříme PVC TypesSubconto.

2.2. Vytvoříme podřízený adresář ValuesSubConto (stejně jako u charakteristik bude obsahovat hodnoty subconto, pokud v jiných adresářích takové nejsou).

2.3. Komunikace probíhá pomocí účtové osnovy.

*************************************************************************************************
Zdroje účetního registru:

Částka - rozvaha,
Množství - podrozvahové a související s účetním znakem Kvantitativní

*************************************************************************************************
Tabulky virtuálního účetního registru:

Obrat: obrat jednoho účtu
TurnoverDtKt: obrat mezi libovolnými dvěma účty, to znamená všechny stejné transakce za dané období.

*************************************************************************************************
Měnové účetnictví na účetních registrech - jak implementovat:

V účtovém rozvrhu vytvoříme účetní atribut „měna“.
V účetní evidenci navíc vytváříme:
- Dimenze měny (zákaz prázdných hodnot, podrozvaha, účetní atribut - měna)
- zdroj CurrencyAmount (podrozvaha, účetní atribut - měna, bude ukládat částku v měně, tj. například 100 $)
Všechno.

Struktura registru je tedy:

Měření:
- Měna
Zdroje
- Množství
- Částka (částka v rublech)
– CurrencyAmount (částka v měně)

Měnové účetnictví je tedy pouze zpřesněním konvenčního účetnictví v Běloruské republice, nemění podstatu např. zdroje Množství
(tam je jako obvykle částka v rublech, bez ohledu na to, zda je účet v cizí měně nebo ne).
A pokud je pro účet vypnutá funkce měny, jedná se o obvyklou strukturu Běloruské republiky (zdroje - pouze množství a množství).

*************************************************************************************************
Při nastavování parametrů virtuální tabulky, abychom získali její část, klademe podmínky na rozměry, nikoli na zdroje.

Jinak nezískáme plátek toho druhého, ale poslední záznam se zadanou hodnotou zdroje – nemusí být poslední v sadě dimenzí

*************************************************************************************************
Význam zdroje a podrobnosti v registru výpočtů

V kalkulačních registrech vytvoření zdroje umožňuje jeho příjem při výpočtu báze pomocí tohoto registru.
A i v poměru k danému období se přepočítá hodnota zdroje (pokud se základní období neshoduje s periodicitou registru).

A hodnota atributu je dostupná pouze v reálné tabulce výpočtového registru, ve virtuálních tabulkách není dostupná.

*************************************************************************************************
Zaškrtávací políčko "Základní" ve vlastnostech rozměru registru výpočtu
Znamená, že toto měření bude v budoucnu použito k získání základny a slouží pro dodatečné indexování hodnoty pro toto pole.

*************************************************************************************************
Rozdělení doby platnosti dovolené podle měsíců při evidenci sad záznamů v registru,
pokud je dovolená v dokumentu uvedena v jednom řádku na několik měsíců najednou v jednom řádku:

StartDate of CurrentMonth = Start of Month(TexLineMainAccruals.ActionPeriodStart); CurrentMonthEndDate = EndMonth(TexLineMainAccruals.ActionPeriodStart); AktuálníMěsíc = Datum; WhileDateStartCurrentMonth<= НачалоМесяца(ТекСтрокаОсновныеНачисления.ПериодДействияКонец) Цикл Движение = Движения.ОсновныеНачисления.Добавить(); Движение.Сторно = Ложь; Движение.ВидРасчета = ТекСтрокаОсновныеНачисления.ВидРасчета; Движение.ПериодДействияНачало = Макс(ДатаНачалаТекМесяца, ТекСтрокаОсновныеНачисления.ПериодДействияНачало); Движение.ПериодДействияКонец = КонецДня(Мин(ДатаОкончанияТекМесяца, ТекСтрокаОсновныеНачисления.ПериодДействияКонец)); Движение.ПериодРегистрации = Дата; Движение.Сотрудник = ТекСтрокаОсновныеНачисления.Сотрудник; Движение.Подразделение = ТекСтрокаОсновныеНачисления.Подразделение; Движение.Сумма = 0; Движение.КоличествоДней = 0; Движение.График = ТекСтрокаОсновныеНачисления.График; Движение.Параметр = ТекСтрокаОсновныеНачисления.Параметр; Движение.БазовыйПериодНачало = НачалоМесяца(ДобавитьМесяц(Дата, -3)); Движение.БазовыйПериодКонец = КонецДня(КонецМесяца(ДобавитьМесяц(Дата, -1))); ДатаНачалаТекМесяца = НачалоМесяца(ДобавитьМесяц(ДатаНачалаТекМесяца, 1)); ДатаОкончанияТекМесяца = КонецМесяца(ДатаНачалаТекМесяца); КонецЦикла; КонецЕсли;

*************************************************************************************************
Vytvoření Ganttova diagramu:

Na formulář umístíme prvek typu „Ganttův diagram“, nazveme jej DG, poté vytvoříme příkaz „Generovat“ a do modulu formuláře zapíšeme:

&Procedura OnClient Generate(Command) GenerateOnServer(); Konec procedury &na serveru Procedura GenerateOn Server() DG.Clear(); DG.Update = False; Request = New Request("SELECT |Basic AccrualsActualActionPeriod.Employee, |BasicAccrualsActualActionPeriod.CalculationType, |Basic AccrualsActualActionPeriod.ActionPeriodStart AS ActionPeriodActionStart, |ABasicAccrualsAccrualsActionPeriod. |Registrace výpočtů.BasicAccruals.ActualPeriodActions AS BasicAccrualsActualPeriodActions |WHERE |BasicAccrualsActualPeriodActions.PeriodActions BETWEEN &StartDate AND &Datum konce "); Query.SetParameter("StartDate", Period.StartDate); Request.SetParameter("EndDate", Period.EndDate); Select = Query.Run().Select(); While Selection.Next() Loop Point = DG.SetPoint(Selection.Employee); Series = DG.SetSeries(Selection.CalculationType); Hodnota = DG.GetValue(Bod, Série); Interval = Value.Add(); Interval.Start = Sample.PeriodActionStart; Interval.End = Sample.ActionPeriodEnd; EndCycle; DG.Update = Pravda; Konec procedury

Tady je pro nás důležitý vlastně jen kód ve smyčce, zbytek věcí je pomocný, jen jsem dal celou implementaci tohoto dílčího úkolu.
V žádosti je pro nás důležité, aby byl uveden zaměstnanec, typ platby, datum začátku a datum konce období.
Kód je ve skutečnosti velmi jednoduchý, snadno zapamatovatelný, nelekejte se, pokud se zdá být těžkopádný

*************************************************************************************************
Zpracování „obrácených“ záznamů ve výpočetních úlohách:

V proceduře zpracování transakcí (modul objektů) tvoříme všechny pohyby, a pokud jsou záznamy v jiných obdobích, získáme je takto
(systém je generuje automaticky - pomáhá nám):

Addition Records = Movements.MainAccruals.GetAddition(); // Není třeba zaznamenávat pohyby pro získání sčítání

Pro každou technologickou řadu z cyklu záznamů přidání
Record = Movements.MainAccruals.Add();
FillPropertyValues(Record, TechString);
Record.RegistrationPeriod = TechString.RegistrationPeriodReversal;
Record.ActionPeriodStart = TechString.ActionPeriodStartReverse;
Record.ActionPeriodEnd = TechString.ActionPeriodEndReversal;
Konec cyklu

A při výpočtu záznamů vložte kontroly:

Pokud TechMotion.Reversal Then
CurrentMovement.Sum = - CurrentMovement.Amount;
endIf;

*************************************************************************************************
Jak určit, co je zahrnuto do hlavního časového rozlišení a co do doplňkového časového rozlišení v kalkulačních úlohách.

Ne vždy je to ale 100% jasné, jsou i složitější případy, i když jich není málo
(např. bonus, který závisí na počtu pracovních dnů v měsíci - to je HE).

Základní poplatky:
Pokud je typ výpočtu závislý na rozvrhu (rozumí se rejstřík informací s kalendářními daty), pak se jedná o hlavní poplatky.

Příklad OH:
- Plat
- Něco, co se počítá z počtu pracovních dnů (a k tomu musíte použít rozvrh): buď v období platnosti (jako plat) nebo v základním období

Další poplatky:
Co se bere v úvahu buď z naběhlé částky, nebo odpracované doby (a ne norma!), nebo vůbec nezávisí - to je další. časové rozlišení.

To znamená: časové rozlišení, pro jehož výpočet se používá časový standard (možná i fakt), je OH a pro které nejsou potřeba skutečná data nebo vůbec nic, je DN.

Nebo jinými slovy:

Pokud VR používá časový standard, pak musí být pro VR zahrnuta doba platnosti.

*************************************************************************************************
Přidejte možnost otevřít vestavěnou sekci nápovědy "Práce s referenčními knihami" ve formuláři seznamu v adresáři "Nomenklatura".

Spusťte příkaz ve formuláři:

&OnClient
Nápověda k postupu (příkaz)
OpenHelp("v8help://1cv8/EnterprWorkingWithCatalogs");
Konec procedury

Čáru řezu definujeme takto:
Přejděte na informace nápovědy ke konfiguračnímu objektu (v konfigurátoru), napište slovo, vyberte jej, přejděte do nabídky Prvky/Odkaz a vyberte požadovanou část nápovědy 1C, za kterou se automaticky vloží odkaz. Vypadá to složitě, ale v praxi je to snadné.

*************************************************************************************************
Implementace interakce mezi formuláři, například výběr:

1. Z aktuálního formuláře otevřete požadovaný pomocí metody „OpenForm()“, přičemž jako druhý parametr (je-li to nutné) předáte strukturu s parametry. Třetí parametr může předat odkaz na tento formulář - ThisForm.

2. V otevřeném formuláři v handleru „When CreatedOnServer()“ můžeme zachytit parametry předané v kroku 1 prostřednictvím „Parameters.[ParameterName]“. Formulář, který inicioval otevření tohoto formuláře, bude přístupný přes identifikátor „Vlastník“ (pokud byl samozřejmě uveden v kroku 1).

A co je nejdůležitější, budou k dispozici exportní funkce formuláře vlastníka. To znamená, že můžeme zavolat funkci exportu zdrojového formuláře a předat tam něco jako parametr pro zpracování výběru. A tato funkce již vyplní, co je potřeba v původním formuláři. Existuje pouze jedno upozornění - nemůžete předat tabulku hodnot mezi klientskými procedurami, ale můžeme ji umístit do dočasného úložiště a jednoduše předat adresu VX a poté ji extrahovat z VX.

*************************************************************************************************
Životní cyklus parametrů formuláře

Všechny parametry přenesené do formuláře při jeho otevření jsou viditelné pouze v proceduře „When CreateOnServer“.
Po vytvoření jsou všechny parametry zničeny a ve formuláři již nejsou k dispozici.
Výjimkou jsou parametry, které jsou deklarovány v editoru formulářů s atributem „Key Parameter“.
Určují jedinečnost formy.
Tento parametr bude existovat, dokud bude existovat samotný formulář.

*************************************************************************************************
Použití rozhraní Taxi

Během vývoje můžete ve vlastnostech konfigurace nastavit obvyklé spravované rozhraní 8.2 - díky tomu je vše znatelně kompaktnější a známější.
To platí zejména, pokud si pronajímáte na dálku - rozlišení obrazovky je velmi malé a s rozhraním „taxi“ není možné nic dělat.
Až budete hotovi, nezapomeňte znovu zadat „Taxi“!V opačném případě zkoušející odečte body!

*************************************************************************************************

PS: E Existují samostatné standardní podúlohy, které se používají ve všech úlohách, a právě ty musíte umět vyřešit (například odepisování po dávkách, použití PVC (no, to je opravdu vzácné) a další). A ve všech úkolech se prostě opakují (někde jsou nějaké dílčí úkoly, jinde jen v různých kombinacích). Navíc už dávno slibují, že vydají novou sbírku (pokud už tak neučinili), ve které by mělo být mnohem více problémů, to znamená, že nemá smysl se učit řešení jednotlivých problémů nazpaměť, má smysl se učit řešit jednotlivé standardní dílčí úkoly, pak vyřešíte jakýkoliv problém.

PSS: Kolegové, pokud má někdo další užitečné informace k přípravě na zkoušku a jejímu složení, napište do komentářů a článek doplníme.

Akumulační registry v systému 1C:Enterprise se dělí na dva typy: akumulační registry zbytky a akumulační registry ot./min.

Typ registru se volí při jeho vytváření v konfigurátoru

Jak název napovídá, některé jsou určeny k získání zůstatků k určitému datu a druhé jsou určeny k získání obratu za zvolené období. V závislosti na typu akumulačního registru generuje platforma 1C:Enterprise jinou sadu virtuálních tabulek. V tomto článku se podíváme na práci s virtuálními tabulkami akumulačních registrů. K tomu vytvoříme registr pro akumulaci zůstatků - Produkty Zbývají a registr akumulace otáček - ProduktyObrat.

Nyní se podívejme, jaké virtuální tabulky platforma poskytuje pro každý z těchto registrů.

Registr akumulace revoluce

Pro přehlednost si otevřeme a podíváme se, které tabulky jsou pro rejstřík k dispozici ProduktyObrat. Toto je tabulka samotného registru - ProduktyObrat, která fyzicky existuje v databázi, a jedna virtuální tabulka - ProduktyTurnover.Turnover

Se standardní tabulkou je vše jasné. Pojďme se blíže podívat na ten virtuální.

Obrat virtuálního stolu

Tato tabulka umožňuje získat obrat zdrojů z hlediska dimenzí. V našem případě máme dva rozměry: Skladem A Produkt. A jeden zdroj - Množství

Nechte náš registr mít následující položky

Vraťme se k návrháři dotazů a začněme jednoduchým výběrem z tabulky ProduktyTurnover.Turnover všechna pole

Podle toho bude žádost vypadat takto:

SELECT ProduktyObratObrat.Sklad, ProduktyObratObrat.Produkt, ProduktyObratObrat.MnožstvíObrat Z RegistruAkumulace.ProduktyObrat.Obrat(,) AS ProduktyObratObrat

Výsledek dotazu vypadá takto:

To znamená, že jsme za celou dobu obdrželi obrat zboží a skladů. Předpokládejme, že nás nezajímají sklady a chceme získat obrat pouze z hlediska zboží.

Za tímto účelem vyjmeme dimenzi z požadavku Skladem

SELECT ProduktyObratObrat.Produkt, Obrat produktuObrat.MnožstvíObrat Z RegistruAkumulace.ProduktyObrat.Obrat(,) AS ProduktyObratObrat

a ve výsledku nám zbydou jen dva řádky

Ale zpravidla není potřeba získávat obrat po celou dobu existence registru. V zásadě jsou potřebné pro určité období: měsíc, čtvrtletí, rok atd. Navíc je obvykle zapotřebí výběr podle rozměrů (produkt, sklad). Toho je dosaženo pomocí parametry virtuální tabulky. Je vhodné vyplnit parametry z konstruktoru. Tlačítkem Možnosti virtuálního stolu Otevře se dialogové okno, ve kterém můžete zadat vše, co potřebujeme:

Poté bude mít naše původní žádost následující podobu

VYBERTE Obrat zboží Obrat.Sklad, Obrat zboží Obrat.Produkt, Obrat zboží Obrat.Množství Obrat Z RegistruAkumulace.Obrat zboží.Obrat(&Začátek období, &Konec období, Sklad = Přechod zboží ASPřechod)

Jak vidíme, rozdíl je v tom, že v závorce za názvem virtuální tabulky jsou parametry, které je nutné před provedením dotazu vyplnit.

Ti, kteří s virtuálními tabulkami teprve začínají, jsou často v pokušení nastavit výběr obvyklým způsobem namísto použití parametrů:

FROM RegisterAccumulations.ProductsObrat.Turnover(,) JAK ProduktyObratObrat KDE ProduktyObratObrat.Sklad = &Sklad

Při vyplňování parametrů nám chyběly Periodicita. Otevřeme seznam a vybereme z množství možných možností Měsíc. Všechny ostatní parametry odstraníme, abychom se nepletli.

Poté pozorujeme, že se v polích tabulky objeví pole Doba.

Přidáním do vybraných polí získáme následující text požadavku:

SELECT ProduktyObratObrat.Období, ProduktyObratObrat.Sklad, ProduktyObrat.Produkt, ProduktyObratObrat.MnožstvíObrat Z RegistruAkumulace.ProduktyObrat.Obrat(, Měsíc,) JAKO ProduktyObratObrat

Vyřídíme požadavek:

V rámci zvoleného časového intervalu tak můžeme otáčky rozdělit na menší intervaly podle zvolené frekvence.

Registr akumulace zůstatku

Stejně jako u reverzního registru se podívejme do návrháře dotazů, které virtuální tabulky jsou k dispozici pro registr akumulace zůstatku

Jak vidíte, pro registr akumulace zůstatku jsou k dispozici tři virtuální tabulky: Revoluce, Zbytky, Zbytky a obraty. Zvažme každou z nich zvlášť.

Obrat virtuálního stolu

Nehledě na to, že typ registru je Zbytky, přesto z něj můžeme přijímat obrat. Navíc zde máme dva další zdroje: Příchod A Spotřeba

Připomínám, že při zápisu do bilančního registru je uveden typ akumulačního pohybu (příjmový nebo výdajový), kdežto u obratového registru se druh pohybu neuvádí. Proto zde máme další bonus v podobě možnosti získat nejen celkový obrat za dané období, ale i příjmy a výdaje zvlášť. Ale samozřejmě, pokud metadata obsahují reverzní registr s podobnou sadou měření, pak je lepší jej použít k získání obratu. Obecně je práce s touto virtuální tabulkou podobná práci s virtuální tabulkou Revoluce výše zmíněný obchodovatelný rejstřík.

Virtuální stůl Zůstatky

Tato tabulka se používá k získání zůstatků zdrojů podle dimenzí. V parametrech tabulky můžeme určit datum, ke kterému obdržíme zůstatky, a nastavit výběr:

Podívejme se na malý příklad. V registru máme následující položky:

Vybereme všechna dostupná pole a jako datum příjmu zůstatků nastavíme konec června. Nebudeme vybírat na základě měření. Text požadavku pak bude vypadat takto:

SELECT ProductsRemainingsRemainings.Warehouse, ProductsRemainingsRemainings.Produkt, ProductsRemainingsRemainings.QuantityRemaining FROM RegisterAkumulace.ProduktyRemainings.Remainings(&DateRemainings,) AS ProduktyRemainingRemainings

A po jeho provedení dostaneme tento výsledek

Virtuální tabulka Zůstatky a obraty

Tato tabulka kombinuje dvě dříve probrané a umožňuje získat obrat za zvolené časové období a také zůstatky na začátku a na konci období. Můžete také nastavit výběr.

Použití této tabulky může být opodstatněné, když potřebujete současně získat obrat i zůstatky na začátku a na konci období v jedné sestavě. V ostatních případech byste jeho použití neměli zneužívat.