Domov Instagram

1c virtuální stůl zůstatky a obrat. Karta Dávka dotazů

Rozhodl jsem se přispět svým příspěvkem a popsat ty rysy jazyka, které nebyly zmíněny ve výše uvedených článcích. Článek je zaměřen na začínající vývojáře.

1. Design „IZ“.

Pro získání dat z databáze není vůbec nutné používat konstrukci „FROM“.
Příklad: Potřebujeme vybrat všechny informace o bankách z adresáře bank.
Žádost:

VYBERTE Adresář.Banky.*

Vybere všechna pole z adresáře Banky. A je podobný požadavku:

SELECT Banks.* FROM Directory.Banks AS Banks

2. Objednací údaje podle referenčního pole

Když potřebujeme uspořádat data dotazu podle primitivních typů: "Řetězec", "Číslo", "Datum" atd., pak je vše vyřešeno pomocí konstrukce "ORDER BY", pokud potřebujete data seřadit podle referenčního pole? Referenční pole je odkaz, jedinečný identifikátor, tzn. Zhruba řečeno, nějaká libovolná sada znaků a běžné řazení může vést k výsledku, který není zcela očekáván. Pro objednání referenčních polí se používá konstrukce "AUTO ORDER". Chcete-li to provést, musíte nejprve seřadit data přímo podle typu odkazu pomocí konstrukce "ORDER BY" a poté pomocí konstrukce "AUTO ORDER".

V tomto případě pro dokumenty proběhne řazení v pořadí "Datum->Číslo", pro referenční knihy v "Hlavním zobrazení". Pokud k řazení nedochází podle referenčních polí, pak použití konstrukce "AUTO ORDER" se nedoporučuje.

V některých případech může konstrukce "AUTO ORDER" zpomalit proces výběru. Podobně můžete přepisovat dokumenty bez automatického řazení:

3. Získání textové reprezentace typu odkazu. "PREZENTAČNÍ" design.

Když potřebujete zobrazit pole referenčního typu, například pole "Banka", což je odkaz na prvek adresáře "Banks", musíte pochopit, že při zobrazení tohoto pole se zobrazí dílčí dotaz na " Automaticky se spustí adresář Banks, aby se získal pohled na adresář. Tím se zpomalí výstup dat. Abyste tomu zabránili, musíte v požadavku použít konstrukci „PREPRESENTATION“, abyste okamžitě získali reprezentaci objektu a následně jej zobrazili k prohlížení.

V systému skládání dat se tento mechanismus používá standardně, ale při vytváření rozložení v buňkách byste měli určit reprezentaci referenčního pole a například umístit samotný odkaz do přepisu.

4. Podmínka pro vzorkování dat podle šablony.

Například potřebujete získat mobilní telefony zaměstnanců formuláře (8 -123- 456-78-912). Chcete-li to provést, musíte v požadavku nastavit následující podmínku:

SELECT Employee.Jmeno, Employee.Phone AS Phone FROM Directory.Employees AS Employees WHERE Phone LIKE "_-___-___-__-__"

Znak "_" je znak služby a nahrazuje jakýkoli znak.

5. Současné použití součtů a seskupení.

Součty se často používají ve spojení se seskupeními; v tomto případě nemusí být v součtech uvedeny agregační funkce.

SELECT Poskytování služeb.Organizace AS Organizace, Poskytování služeb.Nomenklatura AS Nomenklatura, SUM(Poskytování služeb.Částka dokumentu) AS Součet dokumentu Z dokumentu.Poskytování služeb AS Poskytování služeb SKUPINA BY Poskytování služeb.Organizace, poskytování of Services.Nomenklatura VÝSLEDKY PODLE OBECNÝCH, Organizace, Nomen klatura

V tomto případě se dotaz vrátí téměř stejně jako následující dotaz:

SELECT Poskytování služeb.Organizace AS Organizace, Poskytování služeb.Nomenklatura AS Nomenklatura, Poskytování služeb.Částka dokumentu AS Množství dokumentu Z dokumentu.Poskytování služeb AS Poskytování služeb VÝSLEDKY ČÁSTKA (Částka dokumentu) OBECNĚ, Organizace, Nomenklatura

Pouze první dotaz sbalí záznamy se stejnou nomenklaturou.

6. Dereferencování polí.

Odkazování na pole pomocí tečky se nazývá operace dereferencování referenčního pole. Například Platební.Organizace.Administrativní jednotka. V tomto případě se v referenčním poli „Organizace“ dokladu „Platba“ odkazuje na další tabulku „Organizace“, ve které bude získána hodnota atributu „Administrativní jednotka“. Je důležité pochopit, že při přístupu k polím pomocí tečky platforma implicitně vytvoří poddotaz a připojí tyto tabulky.

Žádost:

Může být reprezentován jako:

SELECT Payment.Link, Payment.Organization, Payment.Organization, Organizations. AdministrativeUnit FROM Document.Payment AS Payment LEFT JOIN Directory.Organizations AS Organizations Software Payment.Organization = Organizations.Link

Při dereferencování referenčních polí složeného typu se framework pokusí vytvořit implicitní spojení se všemi tabulkami, které jsou součástí typu daného pole. V tomto případě nebude dotaz optimální, pokud je jasně známo, o jaký typ pole se jedná, je nutné taková pole podle typu omezit konstrukcí VYJÁDŘIT().

Existuje například akumulační registr „Nerozdělené platby“, kde může několik dokumentů fungovat jako registrátor. V tomto případě je nesprávné získat hodnoty údajů o registrátorovi tímto způsobem:

SELECT UnallocatedPayments.Register.Date, ..... FROM RegisterAccumulation.UnallocatedPayments AS UnallocatedPayments

měli byste omezit typ složeného pole na logger:

SELECT EXPRESS(UnallocatedPayments.Register AS Document.Platba).Datum, ..... FROM RegisterAccumulation.UnallocatedPayments AS UnallocatedPayments

7. Konstrukce "KDE"

Při levém spojení dvou stolů, když na pravý stůl uložíte podmínku „KDE“, dostaneme výsledek podobný výsledku s vnitřním spojením stolů.

Příklad. Je nutné vybrat všechny Klienty z Adresáře klientů a pro ty klienty, kteří mají platební doklad s hodnotou atributu "Organizace" = &Organizace, zobrazit doklad "Platba", pro ty, kteří jej nemají, nezobrazovat.

Výsledek dotazu vrátí záznamy pouze pro ty klienty, kteří měli v parametru platbu podle organizace, a odfiltruje ostatní klienty. Proto musíte nejprve přijmout všechny platby pro „takou a takovou“ organizaci v dočasné tabulce a poté ji připojit k adresáři „Klienti“ pomocí levého spojení.

SELECT Payment.Link AS Platba, Payment.Akcionář JAKO Klient MÍSTO doPlatby Z dokumentu.Platba JAKO platba WHERE Payment.Pobočka = &Pobočka; ///////////////////////////////////////////////// /////////////////////////// SELECT Clients.Link AS Client, ISNULL(tPayment.Payment, "") JAKO platba Z adresáře .Clients AS Klienti OPUSTILI SPOJENÍ k platbám JAKO k platbám SOFTWARE Klienti.Odkaz = k platbám.Klient

Tento stav můžete obejít i jinak. Je nutné uložit podmínku "KDE" přímo na vztah mezi dvěma tabulkami. Příklad:

SELECT Clients.Link, Payment.Link FROM Directory.US_Subscribers AS US_Subscribers LEVÉ PŘIPOJENÍ Document.Payment AS Payment Software (Clients.Link = Payment.Client AND Payment.Client.Name LIKE "Sugar Packet") SESKUPIT PODLE Clients.Link, Payment. Odkaz

8. Spojuje se s vnořenými a virtuálními tabulkami

Vnořené dotazyčasto nutné získat data na základě nějaké podmínky. Pokud je poté použijete ve spojení s jinými tabulkami, může to kriticky zpomalit provádění dotazu.

Například u některých klientů potřebujeme získat Částku zůstatku k aktuálnímu datu.

SELECT UnallocatedPaymentsRemains.Customer, UnallocatedPaymentsRemains.AmountRemaining FROM (SELECT Clients.Link AS Link FROM Directory.Clients AS Clients WHERE Clients.Link IN(&Clients)) AS NestedQuery LEFT JOIN RegisterAccumulations.UnallocatedPayments ASPayments.Linky zůstatky. Zákazník

Při provádění takového dotazu může optimalizátor DBMS udělat chyby při výběru plánu, což povede k neoptimálnímu provedení dotazu. Při spojování dvou tabulek vybere optimalizátor DBMS algoritmus spojování tabulek na základě počtu záznamů v obou tabulkách. Pokud existuje vnořený dotaz, je extrémně obtížné určit počet záznamů, které vnořený dotaz vrátí. Proto byste měli vždy místo vnořených dotazů používat dočasné tabulky. Pojďme tedy žádost přepsat.

SELECT Clients.Link AS Link PLACE tClients FROM Directory.Clients AS Clients WHERE
Clients.Link B (&Klienti) ; ///////////////////////////////////////////////// /////////////////////////// VYBERTE tClients.Link, UnallocatedPaymentsRemains.AmountRemaining, Z tClients JAKO tClients LEVÉ PŘIPOJIT SE RegisterAccumulations.UnallocatedPayments.Balances (, Client IN (SELECT tClients.Link FROM tClients)) AS UnallocatedPaymentsBalances tClients.Link = UnallocatedPaymentsBalances.Clients

V tomto případě bude optimalizátor schopen určit, kolik záznamů dočasná tabulka tClients používá, a bude schopen vybrat optimální algoritmus pro spojování tabulek.

Virtuální stoly , umožňují získat prakticky hotová data pro většinu aplikovaných úloh.(Slice of the First, Slice of the Last, Remains, Turnovers, Remains and Turnovers) Zde je klíčové slovo virtuální. Tyto tabulky nejsou fyzické, ale jsou sestavovány systémem za chodu, tzn. Při příjmu dat z virtuálních tabulek systém sbírá data z tabulek finálních registrů, sestavuje, seskupuje a vydává je uživateli.

Tito. Při připojení k virtuální tabulce se vytvoří připojení k dílčímu dotazu. V tomto případě může optimalizátor DBMS zvolit i neoptimální plán připojení. Pokud dotaz není generován dostatečně rychle a dotaz používá spojení ve virtuálních tabulkách, pak se doporučuje přesunout přístup k virtuálním tabulkám do dočasné tabulky a poté provést spojení mezi dvěma dočasnými tabulkami. Přepišme předchozí požadavek.

SELECT Clients.Link AS PLACE Link tClients FROM Directory.Clients AS Clients INDEX BY Link WHERE
Clients.Link B (&Klienti) ; ///////////////////////////////////////////////// /////////////////////////// VYBERTE UnallocatedPayments.AmountBalance, UnallocatedPayments.Client JAKO zůstatky MÍSTA klienta Z registru RegisterAccumulations.UnallocatedPayments.Balances(, Client B ( SELECT tClients. Link FROM tClients)) AS UnallocatedPaymentsBalances; ///////////////////////////////////////////////// /////////////////////////// VYBERTE tClients.Link, toRemainders.AmountRemaining JAKO Částka Zbývající Z tClients JAKO tClients LEVÉ PŘIPOJTE SE k Remainders AS Remainders BY tClients.Link. = tZbytky.Klient

9.Kontrola výsledku požadavku.

Výsledek dotazu může být prázdný; pro kontrolu prázdných hodnot použijte následující konstrukci:

ResRequest = Request.Execute(); If resQuery.Empty() Then Return; endIf;

Metoda Prázdný() by měly být použity před metodami Vybrat() nebo Vyložit(), protože načtení sbírky nějakou dobu trvá.

Pro nikoho není zjevením, že je extrémně nežádoucí používat dotazy ve smyčce. To může kriticky ovlivnit provozní dobu konkrétní funkce. Je velmi žádoucí přijmout všechna data v požadavku a následně je zpracovat ve smyčce. Někdy však nastanou případy, kdy je nemožné přesunout požadavek mimo smyčku. V tomto případě můžete kvůli optimalizaci přesunout vytváření dotazu mimo smyčku a ve smyčce nahradit potřebné parametry a provést dotaz.

To ušetří systém od syntaxe kontroly požadavku ve smyčce.

11. Konstrukce "MÁT".

Design, který je v žádostech poměrně vzácný. Umožňuje stanovit podmínky pro hodnoty agregačních funkcí (SUM, MINIMUM, AVERAGE atd.). Například musíte vybrat pouze ty klienty, jejichž částka platby v září byla více než 13 000 rublů. Pokud použijete podmínku „KDE“, budete muset nejprve vytvořit dočasnou tabulku nebo vnořený dotaz, seskupit tam záznamy podle částky platby a poté podmínku použít. Konstrukce „HAVING“ tomu pomůže předejít.

VYBERTE platbu.Zákazník, ČÁSTKA(Platba.Částka) JAKO Částka Z dokumentu.Platba JAKO Platba KDE MĚSÍC (Datum platby) = 9 SKUPINA PODLE platby.Zákazník MÁ ČÁSTKU (Částka platby) > 13000

Chcete-li to provést, přejděte v konstruktoru na kartu „Podmínky“, přidejte novou podmínku a zaškrtněte políčko „Vlastní“. Pak stačí napsat Částka (Částka platby) > 13 000

12. Hodnota NULL

Nebudu zde popisovat principy trojhodnotové logiky v databázi, článků na toto téma je mnoho. Jen krátce o tom, jak NULA může ovlivnit výsledek dotazu. Hodnota NULL není ve skutečnosti hodnotou a skutečnost, že hodnota není definována, není známa. Proto jakákoli operace s NULL vrací NULL, ať už jde o sčítání, odčítání, dělení nebo srovnání. Hodnotu NULL nelze porovnat s hodnotou NULL, protože nevíme, co porovnávat. Tito. obě tato srovnání jsou: NULL = NULL, NULL<>NULL není True nebo False, není známo.

Podívejme se na příklad.

Pro ty klienty, kteří nemají platby, potřebujeme zobrazit pole „Podepsat“ s hodnotou „Žádné platby“. Navíc s jistotou víme, že takové klienty máme. A abychom odráželi podstatu toho, co jsem napsal výše, udělejme to takto.

VYBERTE "Žádné platby" JAKO Atribut, NULL JAKO MÍSTO dokumentu k platbám; ///////////////////////////////////////////////// ////////////////////////// SELECT Clients.Link AS Client, Payment.Link JAK Platba PUT tClientPayment Z Directory.Clients JAKO klienti LEVÉ PŘIPOJENÍ Dokument. Platba AS Platební software Clients.Link = Payment.Shareholder; ///////////////////////////////////////////////// /////////////////////////// VYBERTE tClientPayment.Client Z tClientPayment JAKO tClientPayment INTERNÍ PŘIPOJENÍ tPayment JAKO tTopay BY tClientPayment.Platba = tPayment.

Věnujte pozornost druhé dočasné tabulce tClientPayment. Levým spojením vybírám všechny klienty a všechny platby pro tyto klienty. Pro klienty, kteří nemají platby, bude pole „Platba“ NULL. Logicky jsem v první dočasné tabulce „tPayments“ označil 2 pole, jedno z nich NULL, druhý řádek „Nemá platby“. Ve třetí tabulce propojuji tabulky „tClientPlatba“ a „tPlatba“ pomocí polí „Platba“ a „Dokument“ s interním spojením. Víme, že v první tabulce je pole „Dokument“ NULL a ve druhé tabulce jsou také NULL ti, kteří nemají platby v poli „Platba“. Co nám takové spojení vrátí? Ale nic to nevrátí. Protože porovnání NULL = NULL se nevyhodnotí jako True.

Aby požadavek vrátil očekávaný výsledek, přepišme jej:

SELECT "Žádné platby" AS atribut, VALUE(Document.Payment.EmptyLink) AS PLACE dokumentu doPayments; ///////////////////////////////////////////////// /////////////////////////// SELECT Clients.Link AS Client, ISNULL(Payment.Link, VALUE(Document.Payment.EmptyLink )) JAK Platba PUT tClientPlatba Z Adresáře.Klienti JAKO Klienti LEVÉ SPOJENÍ Dokument.Platba JAKO platba Klienty.Link = Platba.Podílník; ///////////////////////////////////////////////// /////////////////////////// VYBERTE tClientPayment.Client Z tClientPayment JAKO tClientPayment INTERNÍ PŘIPOJENÍ tPayment JAKO tTopay BY tClientPayment.Platba = tPayment.

Nyní jsme ve druhé dočasné tabulce uvedli, že pokud je pole „Platba“ NULL, pak toto pole = prázdný odkaz na platební doklad. V první tabulce jsme také nahradili NULL prázdnou referencí. Nyní připojení zahrnuje pole jiná než NULL a požadavek vrátí očekávaný výsledek.

Všechny požadavky obsažené v článku odrážejí situace, které bych rád zvážil, a nic víc. O Nemusí být klamné nebo neoptimální, hlavní je, že odrážejí podstatu příkladu.

13. Nezdokumentovaný prvek designu "CHOICE WHEN...THEN...END".

V případě, že je nutné v požadavku popsat konstrukci „Podmínky“, použijeme standardní syntaxi:

VYBERTE VÝBĚR, KDYŽ Users.Name = "Vasya Pupkin" THEN "Náš oblíbený zaměstnanec" ELSE "To nevíme" KONEC JAKO Pole1 Z Directory.Users AS Users

Co když ale například potřebujeme v žádosti získat název měsíce? Zápis velké konstrukce do požadavku je ošklivý a časově náročný, takže výše uvedená forma zápisu nám může pomoci:

VYBERTE MĚSÍC(US_CalculationConsumption_ScheduleTurnover.CalculationPeriod) KDYŽ 1 POTOM "Leden" KDYŽ 2 POTOM "Únor" KDYŽ 3 "Březen" KDYŽ 4 POTOM "Duben" KDYŽ 5, POTOM "Květen" KDYŽ 6 THEN "ČERVEN" KDYŽ 8 PAK "srpen" KDYŽ 9 TAK "září" KDYŽ 10 PAK "říjen" KDYŽ 11 PAK "listopad", KDYŽ 12 PAK "prosinec" KONČÍ JAKO měsíc

Nyní design vypadá méně těžkopádně a je snadno pochopitelný.

14. Dávkové provádění dotazu.

Aby se požadavky nemnožily, můžete vytvořit jeden velký požadavek, rozdělit ho na balíčky a pracovat s ním.
Potřebuji například získat následující pole z adresáře „Users“: „Datum narození“ a dostupné role pro každého uživatele. nahrajte to do různých částí tabulky ve formuláři. Samozřejmě to můžete udělat v jedné žádosti, pak budete muset procházet záznamy nebo je sbalit, nebo můžete udělat toto:

SELECT Users.Link AS Celé jméno, Users.Date of Birth, Users.Role PUT vtUsers FROM Directory.Users AS Users; ///////////////////////////////////////////////// /////////////////////////// SELECT tueUsers.Celé jméno, tueUsers.Datum narození OD tueUsers JAKO tueUsers GROUP BY tueUsers.celé jméno, tueUsers . Datum narození; ///////////////////////////////////////////////// /////////////////////////// VYBRAT wUsers.Celé jméno, wUsers.Role OD wUsers JAKO wUsers GROUP BY wUsers.Celé jméno, wUsers. Datum narození

tPackage = Request.ExecutePackage();

TP_Datum narození = tPackage.Upload();
TP_Roles = tPackage.Unload();

Jak vidíme, dotaz lze provést v dávce a výsledek lze zpracovat jako pole. V některých případech je to velmi pohodlné.

15. Podmínky v požadavku na dávku

Máme například dávkový požadavek, kde nejprve získáme pole: „Jméno, Datum narození, Kód“ z adresáře „Uživatelé“ a chceme získat záznamy s podmínkami pro tato pole z adresáře „Jednotlivci“.

SELECT Users.Individual.Name AS Name, Users.Individual.Date of Birth AS Datum narození, Users.Individual.Code AS Code PLACE vtUsers FROM Directory.Users AS Users; ///////////////////////////////////////////////// /////////////////////////// VYBRAT jednotlivce. Odkaz JAKO jednotlivce Z adresáře. Jednotlivci JAKO Jednotlivci

Můžete si klást takové podmínky:

WHERE Individuals.Code IN (SELECT vtUsers.Code FROM vtUsers) AND Individuals.Name IN (SELECT vtUsers.Code FROM vtUsers) AND Individuals.BirthDate IN (SELECT vtUsers.DateBirth FROM tvUsers)

A můžete to udělat takto:

WHERE (Jednotlivci. Kód, Jednotlivci. Jméno, Jednotlivci. Datum narození) IN (SELECT tueUsers.Code, tueUsers.Name, tueUsers.Date of Birth FROM tueUsers)

Navíc je potřeba udržovat pořádek.

16. Volání tvůrce dotazů pro „stav“ v dávkovém požadavku

Když je nutné uložit podmínku, jako ve výše uvedeném příkladu, můžete zapomenout, jak se to či ono pole volá ve virtuální tabulce.
Například musíte zadat podmínku na pole "Datum narození" a ve virtuální tabulce se toto pole nazývá "Datum narození dlužníka" a pokud zapomenete jméno, budete muset ukončit úpravu podmínky bez uložení a podívejte se na název pole. Abyste tomu zabránili, můžete použít následující techniku.

Za konstrukci „B“ je nutné umístit závorky a mezi závorkami ponechat prázdné místo (mezera), tuto mezeru vybrat a zavolat konstruktor dotazu. Návrhář bude mít přístup ke všem tabulkám dávkového dotazu. Tato technika funguje jak na tabulkách virtuálních registrů, tak na záložce „Podmínky“. V druhém případě je třeba zaškrtnout políčko „P (libovolná podmínka)“ a vstoupit do režimu úprav „F4“.

Dotazy byly často vymýšleny za chodu a slouží pouze k ilustraci „technik“, které jsem zvažoval.

Chtěl jsem se podívat na použití indexů v dotazech, ale to je velmi široké téma. Dám to do samostatného článku, nebo to sem přidám později.

upd1. Body 11,12
upd2. Body 13,14,15,16

Použité knihy:
Dotazovací jazyk "1C:Enterprise 8" - E.Yu. Chrustaleva
Profesní rozvoj v systému 1C:Enterprise 8."

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řevzaty z webu

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.

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.

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.

Vyvoláme dialog pro zadání parametrů virtuální tabulky PriceSliceLast a v parametru ReportDate označíme, že období bude předáno. Chcete-li to provést, vyberte tuto tabulku v seznamu Tabulky a klepněte na tlačítko Možnosti virtuální tabulky. Poté z tabulek vyberte následující pole:

Nomenklatura Spr. Rodič,

CenySlice of Latest.Price.

Spojení levého stolu

- Na záložce Spojení: v poli Link condition, že hodnota dimenze Nomenclature registru informací se musí rovnat odkazu na prvek adresáře Nomenclature. A také zrušte zaškrtnutí políčka Vše pro tabulku registrů a zaškrtněte jej pro vyhledávací tabulku, čímž nastavíte typ připojení jako levé připojení pro vyhledávací tabulku:

Rýže. 13.15. Vztah mezi tabulkami v dotazu

- Na záložce Podmínky nastavíme podmínku pro výběr prvků z adresáře Nomenclature - vybrané prvky musí odpovídat typu nomenklatury předávanému v parametru požadavku Nomenclature Type:

Rýže. 13.16. Podmínky pro výběr prvků

- Na záložce Sdružení/aliasy: zadejte alias pole Parent = Service Group a pole Link = Service. - Klikněte na OK-

Poté musíte upravit schéma rozložení dat, abyste to udělali na kartě Zdroje, klikněte na tlačítko přidat a vyberte zdroj - Cena

- Na záložce Možnosti nastavte hodnotu parametru Nomenclature Type - Enumeration.Nomenclature Types.Service. Kromě toho odstraníme omezení dostupnosti pro parametr ReportDate. V poli Typ tohoto parametru nastavte složení data - Datum. Pro parametr Období naopak nastavíme omezení dostupnosti:

Rýže. 13.17. Možnosti schématu rozložení

Nastavení

- Pojďme k záložce Nastavení: Vytvořme seskupení na základě pole Skupina služeb, určující typ seskupení Hierarchie.

Pro seskupení sestav existují následující typy hierarchie: Bez hierarchie - v seskupení jsou zobrazeny pouze nehierarchické záznamy. Hierarchie - v seskupení jsou zobrazeny jak nehierarchické, tak hierarchické záznamy. Pouze hierarchie - v seskupení jsou zobrazeny pouze hierarchické (nadřazené) záznamy. Uvnitř této skupiny vytvoříme další, aniž bychom uváděli pole skupiny. Na podzáložce Vybraná pole: zadejte výstupní pole Služba a Cena:

Rýže. 13.18. Struktura zprávy a pole

Na podzáložce jiný nastavení provedeme následující kroky:

Rýže. 13.19. Nastavení pro zobrazení obecných součtů pro seskupení "Skupina služeb".

Rýže. 13:20. Nastavení a zobrazení výsledků pro globální přehled

Nakonec zahrneme parametr Datum sestavy do uživatelských nastavení a nastavíme jeho režim úprav na Rychlý přístup. Zavřeme návrhář schématu složení dat a v okně pro úpravu objektu Seznam služeb přejdeme na záložku Subsystémy. V seznamu konfiguračních subsystémů si povšimněte subsystémů Poskytování služeb a Účtování.

V režimu 1C: Enterprise

Spusťte 1C:Enterprise v režimu ladění a nejprve otevřete pravidelný registr Ceny. Poté zprávu otestujeme.

Na příkladu této sestavy jsme studovali, jak systém skládání dat získává nejnovější hodnoty z registru periodických informací a jak se zobrazují seskupení podle hierarchie adresářů.

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é nahrání informační databáze (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í dotazy, 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 výše uvedený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, když 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 popisu výše)

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

Vypadá to nějak 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 pro tabulkové části výrazně pomůže ušetřit čas, 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.

V opačném případě nezískáme výřez z nejnovějších, 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
To znamená, že z této dimenze bude v budoucnu získáván základ a slouží k dodatečnému indexování hodnot 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 harmonogramu (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í.

Tedy: č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.