Domov Instagram

Zostatky a obrat virtuálneho stola 1c. Karta Dávka dopytov

Rozhodol som sa prispieť a opísať tie vlastnosti jazyka, o ktorých sa vo vyššie uvedených článkoch nehovorilo. Článok je určený pre začínajúcich vývojárov.

1. Dizajn „IZ“.

Na získanie údajov z databázy nie je vôbec potrebné použiť konštrukciu „FROM“.
Príklad: Potrebujeme vybrať všetky informácie o bankách z adresára bánk.
Žiadosť:

VYBERTE Adresár.Banky.*

Vyberie všetky polia z adresára Banky. A je podobná požiadavke:

SELECT Banks.* FROM Directory.Banks AS Banks

2. Objednávanie údajov podľa referenčného poľa

Keď potrebujeme usporiadať údaje dotazu podľa primitívnych typov: "Reťazec", "Číslo", "Dátum" atď., potom sa všetko vyrieši pomocou konštrukcie "ORDER BY", ak potrebujete údaje zoradiť podľa referenčného poľa? Referenčné pole je odkaz, jedinečný identifikátor, t.j. Zhruba povedané, nejaká ľubovoľná množina znakov a bežné usporiadanie môže priniesť výsledok, ktorý nie je úplne očakávaný. Pre objednanie referenčných polí sa používa konštrukcia "AUTO ORDER". Aby ste to dosiahli, musíte najprv zoradiť údaje priamo podľa typu odkazu pomocou konštrukcie "ORDER BY" a potom pomocou konštrukcie "AUTO ORDER".

V tomto prípade pre dokumenty bude objednávanie prebiehať v poradí "Dátum->Číslo", pre referenčné knihy v "Hlavnom zobrazení". Ak sa objednávanie nevyskytuje podľa referenčných polí, použitie konštrukcie "AUTO OBJEDNÁVKA" sa neodporúča.

V niektorých prípadoch môže konštrukcia „AUTO OBJEDNÁVKA“ spomaliť proces výberu. Podobne môžete prepísať dokumenty bez automatického objednávania:

3. Získanie textovej reprezentácie typu odkazu. "PREZENTAČNÝ" dizajn.

Keď potrebujete zobraziť pole referenčného typu, napríklad pole „Banka“, ktoré je odkazom na prvok adresára „Banks“, musíte pochopiť, že pri zobrazení tohto poľa sa zobrazí poddotaz na „ Automaticky sa spustí adresár Banky, aby sa získal pohľad na adresár. Tým sa spomalí výstup údajov. Aby ste tomu zabránili, musíte v požiadavke použiť konštrukciu „PREPRESENTATION“, aby ste okamžite získali zobrazenie objektu a následne ho zobrazili na prezeranie.

V systéme skladania údajov sa tento mechanizmus používa štandardne, ale pri vytváraní rozložení v bunkách by ste mali určiť reprezentáciu referenčného poľa a napríklad umiestniť samotný odkaz do prepisu.

4. Podmienka odberu údajov podľa šablóny.

Napríklad musíte získať mobilné telefóny zamestnancov formulára (8 -123- 456-78-912). Ak to chcete urobiť, musíte v žiadosti nastaviť nasledujúcu podmienku:

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

Znak "_" je servisný znak a nahrádza akýkoľvek znak.

5. Súčasné používanie súčtov a zoskupení.

Súčty sa často používajú v spojení so zoskupeniami; v tomto prípade nemusia byť v súčtoch špecifikované súhrnné funkcie.

SELECT Poskytovanie služieb.Organizácia AS Organizácia, Poskytovanie služieb.Nomenklatúra AS Nomenklatúra, SUM(Poskytovanie služieb.Suma dokumentu) AKO Suma dokumentu Z dokumentu.Poskytovanie služieb AS Poskytovanie služieb SKUPINA BY Poskytovanie služieb.Organizácia, poskytovanie of Services.Nomenklatúra VÝSLEDKY PODĽA VŠEOBECNÝCH, Organizácia, Nomen klatura

V tomto prípade sa dotaz vráti takmer rovnako ako nasledujúci dotaz:

SELECT Poskytovanie služieb.Organizácia AS Organizácia, Poskytovanie služieb.Nomenklatúra AS Nomenklatúra, Poskytovanie služieb.Suma dokumentu AS Množstvo dokumentu Z dokumentu.Poskytovanie služieb AKO Poskytovanie služieb VÝSLEDKY SUMA (Suma dokumentu) PODĽA VŠEOBECNÝCH, Organizácia, Nomenklatúra

Iba prvý dotaz zbalí záznamy s rovnakou nomenklatúrou.

6. Dereferencovanie polí.

Odkazovanie na polia cez bodku sa nazýva operácia dereferencovania referenčného poľa. Napríklad Platobná.Organizácia.Administratívna jednotka. V tomto prípade v referenčnom poli „Organizácia“ dokladu „Platba“ odkazuje na inú tabuľku „Organizácie“, v ktorej sa získa hodnota atribútu „Administratívna jednotka“. Je dôležité pochopiť, že pri prístupe k poliam cez bodku platforma implicitne vytvorí poddotaz a spojí tieto tabuľky.

Žiadosť:

Môže byť reprezentovaný ako:

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

Pri dereferencovaní referenčných polí zloženého typu sa framework pokúša vytvoriť implicitné spojenia so všetkými tabuľkami, ktoré sú súčasťou typu daného poľa. V tomto prípade dotaz nebude optimálny, ak je jasne známe, o aký typ poľa ide, je potrebné takéto polia podľa typu obmedziť konštruktom EXPRESNÉ().

Napríklad existuje akumulačný register „Nerozložené platby“, kde môže ako registrátor pôsobiť niekoľko dokumentov. V tomto prípade je nesprávne získať hodnoty údajov registrátora týmto spôsobom:

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

mali by ste obmedziť typ zloženého poľa na zapisovač:

SELECT EXPRESS(Nepriradené platby.Registrovať sa ako dokument.Platba).Dátum, ..... FROM RegisterAkumulácia.Nepriradené platby AKO nepriradené platby

7. Konštrukcia "KDE"

Pri ľavom spojení dvoch stolov, keď zadáte podmienku „KDE“ na pravý stôl, dostaneme výsledok podobný výsledku s vnútorným spojením stolov.

Príklad. Je potrebné vybrať všetkých klientov z Adresára klientov a pre tých klientov, ktorí majú platobný doklad s hodnotou atribútu "Organizácia" = &Organizácia, zobraziť doklad "Platba", pre tých, ktorí ho nemajú, nezobrazovať.

Výsledok dotazu vráti záznamy len pre tých klientov, ktorí mali v parametri platbu podľa organizácie a odfiltruje ostatných klientov. Preto musíte najskôr prijať všetky platby pre „takú a takúto“ organizáciu v dočasnej tabuľke a potom ju pripojiť k adresáru „Klienti“ pomocou ľavého spojenia.

SELECT Payment.Link AS Platba, Platba.Akcionár AKO Klient MIESTO doPlatby Z dokumentu.Platba AKO platba WHERE Platba.Pobočka = &Pobočka; ///////////////////////////////////////////////// /////////////////////////// SELECT Clients.Link AS Client, ISNULL(tPayment.Payment, "") AKO platba z adresára .Clients AS Klienti OPUSTILI PRIPOJENIE k platbám AKO k platbám SOFTVÉR Klienti.Odkaz = k platbám.Klient

Tento stav môžete obísť aj inak. Je potrebné uložiť podmienku "KDE" priamo na vzťah medzi dvoma tabuľkami. Príklad:

VYBERTE Clients.Link, Payment.Link FROM Directory.US_Subscribers AS US_Subscribers LEFT CONECTION Document.Payment AS Payment Software (Clients.Link = Payment.Client AND Payment.Client.Name LIKE "Sugar Packet") GROUP BY Clients.Link, Payment. Link

8. Pripojí sa k vnoreným a virtuálnym stolom

Vnorené dopytyčasto potrebné na získanie údajov na základe určitých podmienok. Ak ich potom použijete v spojení s inými tabuľkami, môže to kriticky spomaliť vykonávanie dotazu.

Napríklad u niektorých klientov potrebujeme získať Čiastku zostatku k aktuálnemu dátumu.

SELECT UnallocatedPaymentsRemains.Customer, UnallocatedPaymentsRemains.AmountRemaining FROM (SELECT Clients.Link AS Link FROM Directory.Clients AS Clients WHERE Clients.Link IN(&Klienti)) AS NestedQuery LEFT JOIN RegisterAccumulations.UnallocatedRequestedPayments.Linky zostatky. Zákazník

Pri vykonávaní takéhoto dotazu môže optimalizátor DBMS urobiť chyby pri výbere plánu, čo povedie k neoptimálnemu vykonaniu dotazu. Pri spájaní dvoch tabuliek optimalizátor DBMS vyberie algoritmus spájania tabuliek na základe počtu záznamov v oboch tabuľkách. Ak existuje vnorený dopyt, je mimoriadne ťažké určiť počet záznamov, ktoré vnorený dopyt vráti. Preto by ste mali vždy používať dočasné tabuľky namiesto vnorených dotazov. Tak poďme prepísať žiadosť.

SELECT Clients.Link AS Link PLACE tClients FROM Directory.Clients AS Clients WHERE
Clients.Link B (&Klienti) ; ///////////////////////////////////////////////// /////////////////////////// VYBERTE tClients.Link, UnallocatedPaymentsRemains.AmountRemaining, Z tClients AKO tClients LEFT PRIPOJTE SA RegisterAccumulations.UnallocatedPayments.Balances (, Client IN (SELECT tClients.Link FROM tClients)) AS UnallocatedPaymentsBalances tClients.Link = UnallocatedPaymentsBalances.Clients

V tomto prípade bude optimalizátor schopný určiť, koľko záznamov používa dočasná tabuľka tClients a bude schopný vybrať optimálny algoritmus na spájanie tabuliek.

Virtuálne stoly , umožňujú získať prakticky hotové dáta pre väčšinu aplikovaných úloh.(Plátok prvého, Slice posledného, Zvyšky, Obraty, Zvyšky a Obraty) Kľúčové slovo je tu virtuálne. Tieto tabuľky nie sú fyzické, ale zostavuje ich systém za chodu, t.j. Pri príjme údajov z virtuálnych tabuliek systém zbiera údaje z tabuliek finálnych registrov, zostavuje, zoskupuje a vydáva ich užívateľovi.

Tie. Pri pripájaní k virtuálnej tabuľke sa vytvorí pripojenie k poddotazu. V tomto prípade môže optimalizátor DBMS zvoliť aj neoptimálny plán pripojenia. Ak sa dotaz negeneruje dostatočne rýchlo a dotaz používa spojenia vo virtuálnych tabuľkách, potom sa odporúča presunúť prístup k virtuálnym tabuľkám do dočasnej tabuľky a potom vytvoriť spojenie medzi dvoma dočasnými tabuľkami. Prepíšme predchádzajúcu požiadavku.

SELECT Clients.Link AS PLACE Link tClients FROM Directory.Clients AS Clients INDEX BY Link WHERE
Clients.Link B (&Klienti) ; ///////////////////////////////////////////////// /////////////////////////// SELECT UnallocatedPayments.AmountBalance, UnallocatedPayments.Client AS zostatky MIESTO klienta Z RegisterAccumulations.UnallocatedPayments.Balances(, Client B ( SELECT tClients. Link FROM tClients)) AS UnallocatedPaymentsZostatky; ///////////////////////////////////////////////// /////////////////////////// SELECT tClients.Link, toRemainders.AmountRemaining AS Suma Remaining FROM tClients AS tClients LEFT JOIN toRemainders AS Remains BY tClients.Link. = tRemainings.Client

9.Kontrola výsledku požiadavky.

Výsledok dotazu môže byť prázdny; na kontrolu prázdnych hodnôt použite nasledujúci konštrukt:

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

Metóda Prázdne () by sa mali použiť pred metódami Vybrať () alebo Uvoľniť (), keďže načítanie zbierky si vyžaduje čas.

Pre nikoho nie je zjavné, že je extrémne nežiaduce používať dopyty v slučke. To môže kriticky ovplyvniť prevádzkový čas konkrétnej funkcie. Je veľmi žiaduce prijať všetky údaje v požiadavke a potom tieto údaje spracovať v slučke. Niekedy však existujú prípady, keď je nemožné presunúť požiadavku mimo slučku. V tomto prípade môžete kvôli optimalizácii presunúť vytváranie dotazu mimo slučku a v slučke nahradiť potrebné parametre a spustiť dotaz.

Toto ušetrí systém od syntaxe kontroly požiadavky v slučke.

11. Konštrukcia „MAŤ“.

Dizajn, ktorý je v žiadostiach pomerne zriedkavý. Umožňuje nastaviť podmienky na hodnoty agregovaných funkcií (SUM, MINIMUM, AVERAGE atď.). Napríklad musíte vybrať iba tých klientov, ktorých výška platby v septembri bola viac ako 13 000 rubľov. Ak použijete podmienku „KDE“, budete musieť najskôr vytvoriť dočasnú tabuľku alebo vnorený dotaz, zoskupiť tam záznamy podľa sumy platby a potom použiť podmienku. Konštrukcia „HAVING“ tomu pomôže vyhnúť sa.

VYBERTE Platba.Zákazník, SUMA(Platba.Suma) AKO Suma Z dokumentu.Platba AKO platba KDE MESIAC (Dátum platby) = 9 SKUPINA PODĽA platby.Zákazník MÁ SUMU (Suma platby) > 13 000

Ak to chcete urobiť, v konštruktore prejdite na kartu „Podmienky“, pridajte novú podmienku a začiarknite políčko „Vlastné“. Potom stačí napísať Suma (suma platby) > 13 000

12. Hodnota NULL

Nebudem tu popisovať princípy trojhodnotovej logiky v databáze, na túto tému je veľa článkov. Len v skratke ako NULOVÝ môže ovplyvniť výsledok dotazu. Hodnota NULL v skutočnosti nie je hodnotou a skutočnosť, že hodnota nie je definovaná, nie je známa. Preto každá operácia s NULL vráti NULL, či už ide o sčítanie, odčítanie, delenie alebo porovnanie. Hodnotu NULL nemožno porovnávať s hodnotou NULL, pretože nevieme, čo porovnávať. Tie. obe tieto porovnania sú: NULL = NULL, NULL<>NULL nie je pravda ani nepravda, nie je známa.

Pozrime sa na príklad.

Pre tých klientov, ktorí nemajú platby, potrebujeme zobraziť pole „Podpísať“ s hodnotou „Žiadne platby“. Navyše s istotou vieme, že takýchto klientov máme. A aby sme odrážali podstatu toho, čo som napísal vyššie, urobme to takto.

VYBERTE AKO Atribút "Žiadne platby", NULL AKO MIESTO dokumentu k platbám; ///////////////////////////////////////////////// ////////////////////////// SELECT Clients.Link AS Client, Payment.Link AKO Platba ULOŽIŤ tClientPlatbu Z Directory.Clients AKO Klienti ĽAVÉ PRIPOJENIE Dokument. Platba AS Platobný softvér Clients.Link = Payment.Shareholder; ///////////////////////////////////////////////// /////////////////////////// VYBERTE tClientPayment.Client Z tClientPayment AKO tClientPayment INTERNÉ PRIPOJENIE tPayment AKO tTopay BY tClientPayment.Platba = tPlatba. Dokument

Venujte pozornosť druhej dočasnej tabuľke tClientPayment. Ľavým spojením vyberiem všetkých klientov a všetky platby pre týchto klientov. Pre klientov, ktorí nemajú platby, bude pole „Platba“ NULL. Podľa logiky som v prvej dočasnej tabuľke „tPayments“ označil 2 polia, jedno z nich NULL, druhé riadok „Nemá platby“. V tretej tabuľke spájam tabuľky “tClientPlatba” a “tPlatba” pomocou polí “Platba” a “Doklad” s interným spojením. Vieme, že v prvej tabuľke je pole „Dokument“ NULL a v druhej tabuľke sú NULL aj tí, ktorí nemajú platby v poli „Platba“. Čo nám takéto spojenie vráti? Ale nič to nevráti. Pretože porovnanie NULL = NULL sa nevyhodnotí ako True.

Aby žiadosť vrátila očakávaný výsledok, prepíšme ju:

VYBERTE AKO Atribút "Žiadne platby", VALUE(Document.Payment.EmptyLink) AKO DOKUMENT PLACE toPayments; ///////////////////////////////////////////////// /////////////////////////// SELECT Clients.Link AS Client, ISNULL(Payment.Link, VALUE(Document.Payment.EmptyLink )) AKO Platba PUT tKlientPlatba Z Adresára.Klienti AKO Klienti ĽAVÉ SPOJENIE Dokument.Platba AKO platba Klientmi.Odkaz = Platba.Akcionár; ///////////////////////////////////////////////// /////////////////////////// VYBERTE tClientPayment.Client Z tClientPayment AKO tClientPayment INTERNÉ PRIPOJENIE tPayment AKO tTopay BY tClientPayment.Platba = tPlatba. Dokument

Teraz sme v druhej dočasnej tabuľke uviedli, že ak je pole „Platba“ NULL, potom toto pole = prázdny odkaz na platobný doklad. V prvej tabuľke sme tiež nahradili NULL prázdnou referenciou. Teraz pripojenie zahŕňa polia bez NULL a požiadavka vráti očakávaný výsledok.

Všetky požiadavky obsiahnuté v článku odrážajú situácie, ktoré by som chcel zvážiť, a nič viac. O Nemusia byť klamné alebo suboptimálne, hlavné je, že odrážajú podstatu príkladu.

13. Nezdokumentovaná vlastnosť dizajnu „VOĽBA, KEĎ...VTEDY...KONIEC“.

V prípade, že je potrebné v požiadavke popísať konštrukciu „Podmienky“, použijeme štandardnú syntax:

VYBERTE VÝBER, KEĎ Users.Name = "Vasya Pupkin" THEN "Náš obľúbený zamestnanec" ELSE "Toto nevieme" KONIEC AKO Pole1 Z Adresára.Používatelia AKO Používatelia

Čo ak však napríklad potrebujeme v žiadosti získať názov mesiaca? Písanie obrovskej konštrukcie do žiadosti je škaredé a časovo náročné, takže táto forma písania vyššie nám môže pomôcť:

VYBERTE MESIAC(US_CalculationConsumption_ScheduleTurnover.CalculationPeriod) KEDY 1 POTOM "Január" KEĎ 2 POTOM "Február" KEĎ 3. POTOM "Marec" KEĎ 4 POTOM "Apríl" KEĎ 5. POTOM "Máj" KEĎ 6. THEN "JÚN" KEĎ 8 POTOM "august" KEĎ 9 POTOM "september" KEĎ 10 POTOM "október" KEĎ 11 POTOM "november" KEĎ 12 POTOM KONČÍ "december" AKO mesiac

Teraz dizajn vyzerá menej ťažkopádne a je ľahko pochopiteľný.

14. Dávkové vykonanie dotazu.

Aby sa požiadavky nemnožili, môžete vytvoriť jednu veľkú požiadavku, rozdeliť ju do balíkov a pracovať s ňou.
Napríklad potrebujem získať nasledujúce polia z adresára „Používatelia“: „Dátum narodenia“ a dostupné roly pre každého používateľa. nahrajte to do rôznych častí tabuľky vo formulári. Samozrejme, môžete to urobiť v jednej požiadavke, potom budete musieť prechádzať záznamy alebo ich zbaliť, alebo môžete urobiť toto:

SELECT Users.Link AS Celé meno, Users.Date of Birth, Users.Role PUT vtUsers FROM Directory.Users AS Users; ///////////////////////////////////////////////// /////////////////////////// VYBERTE tueUsers.Celé meno, tueUsers.Dátum narodenia OD tueUsers AKO tueUsers GROUP BY tueUsers.celé meno, tueUsers . Dátum narodenia; ///////////////////////////////////////////////// //////////////////////////// VYBERTE wUsers.Celé meno, wUsers.Rola OD wUsers AKO wUsers GROUP BY wUsers.Celé meno, wUsers. Dátum narodenia

tPackage = Request.ExecutePackage();

TP_Dátum narodenia = tPackage.Upload();
TP_Roles = tPackage.Unload();

Ako vidíme, dotaz môže byť vykonaný v dávke a výsledok môže byť spracovaný ako pole. V niektorých prípadoch je to veľmi pohodlné.

15. Podmienky v žiadosti o dávku

Napríklad máme dávkovú požiadavku, kde najskôr získame polia: „Meno, Dátum narodenia, Kód“ z adresára „Používatelia“ a chceme získať záznamy s podmienkami pre tieto polia z adresára „Jednotlivci“.

SELECT Users.Individual.Name AS Meno, Users.Individual.Date of Birth AS Dátum narodenia, Users.Individual.Code AS Code PLACE vtUsers FROM Directory.Users AS Users; ///////////////////////////////////////////////// //////////////////////////// VYBRAŤ jednotlivcov. Prepojiť AKO Jednotlivec Z adresára. Jednotlivci AKO Jednotlivci

Môžete si stanoviť takéto podmienky:

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 urobiť takto:

WHERE (Individuals.Code, Individuals. Name, Individuals. Date of Birth) IN (SELECT tueUsers.Code, tueUsers.Name, tueUsers.Date of Birth FROM tueUsers)

Okrem toho je potrebné udržiavať poriadok.

16. Volanie tvorcu dotazov pre „stav“ v dávkovej požiadavke

Keď je potrebné zadať podmienku, ako v príklade vyššie, môžete zabudnúť na to, ako sa to alebo ono pole volá vo virtuálnej tabuľke.
Napríklad musíte zadať podmienku pre pole „Dátum narodenia“ a vo virtuálnej tabuľke sa toto pole nazýva „Dátum narodenia dlžníka“ a ak zabudnete meno, budete musieť ukončiť úpravu podmienky bez uložiť a pozrieť sa na názov poľa. Aby ste tomu zabránili, môžete použiť nasledujúcu techniku.

Za konštrukciou „B“ je potrebné vložiť zátvorky a medzi zátvorkami nechať prázdne miesto (medzeru), vybrať túto medzeru a zavolať konštruktor dotazu. Návrhár bude mať prístup ku všetkým tabuľkám dávkového dotazu. Táto technika funguje na tabuľkách virtuálnych registrov aj na karte „Podmienky“. V druhom prípade je potrebné zaškrtnúť políčko „P (ľubovoľná podmienka)“ a vstúpiť do režimu úprav „F4“.

Otázky boli často vymýšľané za chodu a slúžia len na ilustráciu „techniky“, o ktorej som uvažoval.

Chcel som sa pozrieť na použitie indexov v dotazoch, ale toto je veľmi široká téma. Dám to do samostatného článku alebo to sem pridám neskôr.

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

Použité knihy:
Jazyk dopytu "1C:Enterprise 8" - E.Yu. Khrustaleva
Profesionálny rozvoj v systéme 1C:Enterprise 8."

Pri organizovaní vzoriek v reálnych problémoch sa vo veľkej väčšine prípadov výber údajov organizuje podľa určitých kritérií.

V prípade, že sa výber uskutočňuje zo skutočného stola, nevznikajú žiadne ťažkosti. Údaje sa spracúvajú úplne triviálne:

V prípade, že zdrojom v dotaze je virtuálna tabuľka, situácia sa trochu skomplikuje.

Dopytovací jazyk vám umožňuje uložiť podmienku na výber z virtuálnych tabuliek dvoma spôsobmi: v klauzule WHERE a pomocou parametrov virtuálnej tabuľky. Obe metódy povedú k rovnakému výsledku (s výnimkou niektorých špecifických prípadov), ale nie sú ani zďaleka ekvivalentné.

Už vieme, že virtuálne tabuľky sa nazývajú virtuálne, pretože v skutočnosti nie sú v databáze. Vznikajú až v momente, keď je na ne podaná žiadosť. Napriek tomu je pre nás (teda pre tých, ktorí dopyt píšu) vhodné považovať virtuálne tabuľky za skutočné. Čo sa stane v systéme 1C Enterprise 8, keď dotaz, ktorý sme zostavili, stále pristupuje k virtuálnej tabuľke?

V prvom kroku systém vytvorí virtuálnu tabuľku. V druhom kroku sa z výslednej tabuľky vyberú záznamy, ktoré spĺňajú podmienku špecifikovanú v klauzule WHERE:
Je jasne vidieť, že konečná vzorka nebude obsahovať všetky záznamy z virtuálnej tabuľky (a teda z databázy), ale len tie, ktoré spĺňajú danú podmienku. A zostávajúce záznamy budú z výsledku jednoducho vylúčené.

Systém teda nebude robiť len zbytočnú prácu, ale dvojnásobnú zbytočnú prácu! Najprv sa vynaložia zdroje na vytvorenie virtuálnej tabuľky na základe nepotrebných údajov (na obrázku sú označené ako „oblasť údajov A a B“) a potom sa bude pracovať na filtrovaní týchto údajov z konečného výsledku.

Je možné okamžite, vo fáze vytvárania virtuálnej tabuľky, prestať používať nepotrebné údaje? Ukazuje sa, že je to možné. Presne na to sú určené parametre virtuálnej tabuľky:

Parametrizáciou virtuálnej tabuľky okamžite obmedzíme množstvo dát, ktoré bude dotaz spracovaný.

Aký je rozdiel medzi hodnotami parametra virtuálnej tabuľky "Metóda pridávania"?
Keď je metóda sčítania nastavená na „pohyby“, vrátia sa iba tie obdobia, v ktorých došlo k pohybom. Keď je nastavené "Pohyby a hranice období", potom sa k vyššie uvedeným pohybom pridajú 2 záznamy: pohyby na začiatku a na konci obdobia špecifikovaného v parametroch VT. Pole „Registrátor“ bude pre tieto 2 záznamy prázdne.

Informácie prevzaté zo stránky

Pri organizovaní vzoriek v reálnych problémoch sa vo veľkej väčšine prípadov výber údajov organizuje podľa určitých kritérií.

V prípade, že sa výber uskutočňuje zo skutočného stola, nevznikajú žiadne ťažkosti. Údaje sa spracúvajú úplne triviálne:

V prípade, že zdrojom v dotaze je virtuálna tabuľka, situácia sa trochu skomplikuje.

V prvom kroku systém vytvorí virtuálnu tabuľku. V druhom kroku sa z výslednej tabuľky vyberú záznamy, ktoré spĺňajú podmienku špecifikovanú v klauzule WHERE:

Je jasne vidieť, že konečná vzorka nebude obsahovať všetky záznamy z virtuálnej tabuľky (a teda z databázy), ale len tie, ktoré spĺňajú danú podmienku. A zostávajúce záznamy budú z výsledku jednoducho vylúčené.

Je možné okamžite, vo fáze vytvárania virtuálnej tabuľky, prestať používať nepotrebné údaje? Ukazuje sa, že je to možné. Presne na to sú určené parametre virtuálnej tabuľky:

Parametrizáciou virtuálnej tabuľky okamžite obmedzíme množstvo dát, ktoré bude dotaz spracovaný.

Vyvoláme dialóg pre zadávanie parametrov virtuálnej tabuľky PriceSliceLast a v parametri ReportDate označíme, že obdobie bude prechádzať. Ak to chcete urobiť, vyberte túto tabuľku v zozname Tabuľky a kliknite na tlačidlo Možnosti virtuálnej tabuľky. Potom z tabuliek vyberte nasledujúce polia:

Nomenklatúra Spr. rodič,

CenySlice of Latest.Price.

Ľavý stôl

- Na záložke Spojenia: v poli Podmienka prepojenia, že hodnota dimenzie Nomenklatúra informačného registra sa musí rovnať odkazu na prvok adresára Nomenklatúry. A tiež zrušte začiarknutie políčka Všetky pre tabuľku registrov a začiarknite ho pre vyhľadávaciu tabuľku, čím nastavíte typ pripojenia ako ľavé pripojenie pre vyhľadávaciu tabuľku:

Ryža. 13.15. Vzťah medzi tabuľkami v dotaze

- Na záložke Podmienky nastavíme podmienku výberu prvkov z adresára Nomenklatúra - vybrané prvky musia zodpovedať typu nomenklatúry odovzdanej v parametri požiadavky Typ nomenklatúry:

Ryža. 13.16. Podmienky výberu prvkov

- Na záložke Odbory/aliasy: zadajte alias poľa Parent = Service Group a poľa Link = Service. - Kliknite na tlačidlo OK -

Potom musíte upraviť schému rozloženia údajov, aby ste to urobili na karte Zdroje, kliknite na tlačidlo pridať a vyberte zdroj - cena

- Na záložke možnosti nastavte hodnotu parametra Nomenclature Type - Enumeration.Nomenclature Types.Service. Okrem toho odstránime obmedzenie dostupnosti pre parameter ReportDate. V poli Typ tohto parametra nastavte zloženie dátumu - Dátum. Pre parameter Obdobie naopak nastavíme obmedzenie dostupnosti:

Ryža. 13.17. Možnosti schémy rozloženia

nastavenie

- Poďme na záložku Nastavenie: Vytvorme zoskupenie na základe poľa Skupina služieb, pričom určíme typ zoskupenia Hierarchia.

Pre zoskupenia prehľadov existujú nasledujúce typy hierarchie: Bez hierarchie – v zoskupení sú zobrazené len nehierarchické záznamy. Hierarchia - v zoskupení sú zobrazené nehierarchické aj hierarchické záznamy. Iba hierarchia - v zoskupení sa zobrazujú iba hierarchické (nadradené) záznamy. Vo vnútri tejto skupiny vytvoríme ďalšiu, bez zadania poľa skupiny. Na podzáložke Vybrané polia: zadajte výstupné polia Služba a Cena:

Ryža. 13.18. Štruktúra správy a polia

Na podzáložke Iné nastavenia vykonáme nasledujúce kroky:

Ryža. 13.19. Nastavenia pre zobrazenie všeobecných súčtov pre skupinu "Servisná skupina".

Ryža. 13.20 hod. Nastavenie a zobrazenie výsledkov pre globálny prehľad

Nakoniec zahrňme parameter Report Date do používateľských nastavení a nastavte jeho režim úprav na Rýchly prístup. Zatvorme návrhár schémy kompozície dát a v okne úpravy objektu Zoznam služieb prejdeme na záložku Podsystémy. V zozname konfiguračných podsystémov si všimnite podsystémy Poskytovanie služieb a Účtovníctvo.

V režime 1C: Enterprise

Spustíme 1C:Enterprise v režime ladenia a najprv otvoríme pravidelný register Ceny. Potom správu otestujeme.

Pomocou tohto prehľadu ako príkladu sme študovali, ako systém na zostavovanie údajov získava najnovšie hodnoty z periodického informačného registra a ako sa zobrazujú zoskupenia podľa hierarchie adresárov.

Ak je pre vás moja publikácia užitočná, nezabudnite jej dať plus :-)

Tu je rubrikátor pre všetky úlohy v zbierke(stránka obsahujúca odkazy na vlákna fóra pre každú úlohu)
http://chistov.spb.ru/forum/16-969-1

No, teraz môj vývoj a poznámky, ktoré som vytvoril počas procesu prípravy.
Pokúsim sa čo najmenej opakovať s dvoma vyššie uvedenými posledný publikácií.

Takže začnime:

Ak ju absolvujete na diaľku, na konci skúšky by ste mali mať na pracovnej ploche dva objekty:

1. Konečné nahranie informačnej základne (súbor dt)
2. Vysvetlivka

Nemalo by tam byť nič iné, žiadne prechodné kópie atď.

Nezabudnite napísať vysvetľujúcu poznámku!
V prípade nejasne formulovanej úlohy tam určite napíšte, že ste zvolili presne takú a takú možnosť riešenia.
Na kľúčových miestach v kódexe je tiež lepšie nechať krátke komentáre bez fanatizmu, ale tam, kde môže mať skúšajúci otázky, je lepšie písať.

Ale o tom budete informovaní v pokynoch, ktoré si budete musieť prečítať pred skúškou.
Len je lepšie vedieť vopred)

Používanie znaku ampersand v dopytoch.

Niekedy je rýchlejšie písať z ďalšej klávesnice, než prepínať rozloženie tam a späť, čím sa ušetrí čas
& = Alt+38

*************************************************************************************************
Použitie TimePoint() v dotazoch

V dotazoch do akumulačných a účtovných registrov je potrebné ako parameter virtuálnej tabuľky (obdobia) použiť nie dátum dokladu, ale parameter Moment, ktorý je v kóde definovaný nasledovne:

Moment = ? (Režim prechodu = Režim zaúčtovania dokumentu. Prevádzkový, Nedefinovaný, Moment času ());

*************************************************************************************************
Pri generovaní pohybov dokladov registrom je na samom začiatku procesu spracovania účtovania potrebné vymazať pohyby aktuálneho dokladu registrom.

Kód je:

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

Je možné, že počas procesu bude potrebné analyzovať záznamy z tohto registra.
Aby pri analýze aktuálnych záznamov (starých, pred zmenou dokumentu) určite neboli zahrnuté do vzorky, môžete k vyššie uvedeným dvom riadkom pridať jeden riadok navyše:

Movement.RegisterName.Write();

Alebo pri analýze záznamov explicitne uveďte hranicu, ktorá nezahŕňa časový bod aktuálneho dokumentu.

Ale všade som jednoducho naznačil konštrukciu týchto troch riadkov:

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

*************************************************************************************************
Existujú dva spôsoby blokovania údajov, výber medzi nimi závisí od použitej metódy - stará alebo nová:

1) Pravidelné riadené blokovanie, starý spôsob spracovania dokumentov (objekt Blokovanie údajov)

Nastavte, či sa zostatky najskôr skontrolujú a potom odpíšu.
V prípade, keď na vytvorenie pohybu potrebujeme mať nejaké informácie z registra.

Príklad:

V doklade - množstvo, v evidencii - množstvo a množstvo (náklad)
Z dokladu teda vieme množstvo tovaru - koľko odpisujeme, ale náklady - nie.
Zistíme to len z registra, ale aby nám medzi okamihom prijatia zostatkov a momentom zaznamenania pohybov nikto nezmenil register, potrebujeme register uzamknúť ešte pred načítaním zostatkov.
Takže v tomto prípade sa používa objekt Data Locking. A pri jeho vytváraní je správnejšie uviesť, akými rozmermi blokujeme register (napríklad v našom prípade - iba položkou uvedenou v dokumente) - aby neboli zbytočné zámky a iný používateľ mohol predať ďalšie položka.

1. Nastavte zámok pomocou objektu Data Lock
2. Prečítajte si zvyšok
3. Preverujeme možnosť odpisu
4. Vytvárame pohyby, napríklad odpisujeme tovar
5. Po zaúčtovaní dokladu sa blokácia automaticky odstráni (blokácia je platná v rámci zaúčtovania a je automaticky odstránená systémom). To znamená, že nie je potrebné objekt špeciálne odomykať.

2) Nová metodika spracovania dokumentov (pomocou vlastnosti LockForChange = True)

Používa sa v prípade, že na tvorbu pohybov nepotrebujeme informácie z registrov a či sme pri odpisovaní nešli do mínusu, môžeme si skontrolovať, ak sa po zapísaní pozrieme na zostatky v registri a zistíme, že sú tam záporné. . V tomto prípade pochopíme, že sme odpísali príliš veľa a operáciu odpisu zrušíme.

Príklad:
Zoberme si operáciu predaja produktu.
V doklade - množstvo, v evidencii - len množstvo
Množstvo tovaru teda vieme z dokladu.
Vytvárame pohyby s množstvom uvedeným v doklade a evidujeme ich. Ďalej čítame register, pozeráme sa na zostatky a analyzujeme, či existujú nejaké negatívne. Ak existuje, zobrazte chybu a nastavte Odmietnutie = Pravda.

To znamená, že postupnosť je takáto:
1. Pre pohyb v registri nastavte vlastnosť BlockForChange = True
2. Vytvárame pohyby - odpisujeme tovar
3. Zaznamenajte pohyby
4. Prečítajte si register a uistite sa, že neexistujú žiadne záporné zostatky. Ak existuje, potom prebytok odpísali, ak nie, potom je všetko v poriadku.

Takže v tomto prípade nie je potrebné uvádzať, podľa ktorých rozmerov potrebujeme blokovať register.
Jednoducho nastavíme vlastnosť BlockForChange na True predtým, ako zaznamenáme naše pohyby, vytvoríme pohyby a zaznamenáme.
Samotný systém zablokuje register v čase záznamu podľa meraní, ktoré sú potrebné, po analýze toho, čo sme zaznamenali.
Po dokončení bude blokovanie odstránené.

Táto možnosť (druhá) je jednoduchšia, nazýva sa „nová metodika spracovania dokumentov“ a spoločnosť 1C ju odporúča použiť, ak je to možné, a odpočítava body, ak sa použije prvá možnosť, ale v niektorých prípadoch sa jednoducho nedá použiť a prvá možnosť s používa sa objekt Data Locking (pozri príklad vyššie).

Poznamenávam tiež, že bez ohľadu na zvolenú metódu musia byť pohyby pred prácou s nimi očistené (pozri predchádzajúce rady)

*************************************************************************************************
Blokovanie dát (metóda blokovania č. 1 z popisu vyššie)

Riadené uzamykanie sa vyžaduje tam, kde sa údaje čítajú a na základe týchto údajov sa vykonávajú pohyby
Najrýchlejší spôsob, ako získať spravovaný uzamykací kód, je zadať „Data Locking“, zavolať Syntax Assistant a jednoducho odtiaľ skopírovať vzorový kód. Potom ho jednoducho zmeňte na názov vášho registra a rozmery.

Vyzerá to asi takto:

Lock = NewDataLock; Uzamykací prvok = Uzamknutie.Pridať("Registr akumulácie.TovarVSkladoch"); LockElement.Mode = DataLockMode.Exclusive; BlockingElement.DataSource = PM; Locking Element.UseFromDataSource("Nomenklatúra", "Nomenklatúra"); Lock.Lock();

*************************************************************************************************
Je lepšie nazvať tabuľkovú časť dokumentov jednoducho „TC“

V 99 % dokumentov je len jedna tabuľková časť. Takýto jednotný názov pre tabuľkové časti výrazne pomôže ušetriť čas, pretože:
1) Veľmi krátke - píšte rýchlo
2) To isté pre všetky dokumenty, pri písaní kódu si nemusíte pamätať, ako sa to volá

*************************************************************************************************
Pred načítaním alebo nahraním do technickej špecifikácie by sa mal výsledok dotazu skontrolovať, či nie je prázdny.

Vo všeobecnosti som pri všetkých úlohách používal odber vzoriek.

Vzorkovanie je pre systém z hľadiska výkonu optimálnejšie, keďže je „naostrené“ len na čítanie dát (na rozdiel od TK).

Ale v každom prípade, pred metódou Select() je lepšie skontrolovať výsledok dotazu na prázdnotu, tým sa ešte viac zníži zaťaženie systému.

Vysledok = Query.Run(); If Not Result.Empty() Then Select = Result.Select(TravelQueryResult.ByGrouping); ... Koniec Ak;

A v prípade, že potrebujeme z požiadavky získať len jednu hodnotu
(napríklad len spôsob odpisu v súlade s účtovnou zásadou stanovenou pre tento rok):

Vysledok = Query.Run(); If Not Result.Empty() Then Select = Result.Select(); Selection.Next(); Metóda odpisu nákladov = Vzorka. Metóda odpisu nákladov; koniec Ak;

*************************************************************************************************
Dokument "Operácia" pre účtovnú úlohu

Pre účtovné úkony je potrebné vytvoriť Prevádzkový doklad.

Úplne mu zakážeme účtovanie (vo vlastnostiach „Zaúčtovanie = Zamietnuť“), označíme, že robí pohyby v účtovnej evidencii a presunieme pohyby do formulára.

*************************************************************************************************
Rýchle spracovanie dokumentov:

Musí byť zahrnuté:
V prevádzke a účtovníctve. musí byť povolené účtovanie dokladov (okrem dokladu „Prevádzka“, viď nižšie).

Musí byť vypnutý:
vo výpočtových úlohách nemá zmysel pre mzdový doklad.

Pre doklad "Prevádzka" by malo byť účtovanie úplne zakázané (vo vlastnostiach dokladu "Zaúčtovanie = Zakázať"),
keďže zapisuje jednoducho pri zápise zapisuje údaje priamo do registra.

*************************************************************************************************
Podmienka v žiadosti vo forme "Buď špecifikovaná nomenklatúra alebo akákoľvek, ak nie je špecifikovaná"

V dotazoch sa stretnete s nasledujúcou úlohou: napríklad musíte vybrať dokumenty so zadanou nomenklatúrou alebo všetky dokumenty, ak nomenklatúra nie je zadaná.
Rieši sa to nasledujúcou podmienkou v samotnej žiadosti:

Nomenklatúra = &Nomenklatúra ALEBO &Nomenklatúra = Hodnota(Directory.Nomenclature.EmptyLink)

Optimálnejšie a správnejšie by však bolo zmeniť tento stav (vďaka yukon):

Request.Text = Request.Text + "WHERE Nomenclature = &Nomenklatúra";

koniec Ak;

S príchodom modelu objektu dotazu v 8.3.5 bude možné pridať podmienku bezpečnejšie:

If ValueFilled(Nomenclature) Then
Query1.Selection.Add("Položka = &Nomenklatúra");
Request.SetParameter("Nomenklatúra", Nomenklatúra);
koniec Ak;

*************************************************************************************************
Spájanie stolov v dopytoch:

Počet celkových záznamov nezávisí od toho, či je zobrazené pole spájanej tabuľky, závisí len od nakonfigurovaných vzťahov.
To znamená, že pole priloženej tabuľky sa nemusí zobraziť.

Ak chcete pripojiť tabuľku bez akýchkoľvek podmienok, potom na záložku podmienok jednoducho napíšte podmienku „PRAVDA“.
V tomto prípade bude stôl presne spojený.

*************************************************************************************************
Pomocou plánu typov charakteristík (PVC):

1. Použiť ako mechanizmus na popis vlastností objektov.

1.1. Vyrábame PVC. Pôjde o Typy charakteristík (napríklad farba, veľkosť, max. rýchlosť atď.). V nastaveniach vyberte všetky možné typy charakteristických hodnôt a v prípade potreby vytvorte objekt z bodu 1.2 a tiež ho uveďte v nastaveniach.

1.2. Pre ďalšie hodnoty PVC vytvárame podriadený adresár AdditionalValues of Characteristics (alebo jednoducho Values of Characteristics).
Uloží charakteristiky, ak nie sú v existujúcich adresároch. Nemusíme ho vytvoriť, ak sú všetky potrebné charakteristiky v existujúcich adresároch, alebo tieto hodnoty môžu byť reprezentované elementárnymi dátovými typmi. V nastaveniach PVC uvádzame, že tento adresár bude použitý na ďalšie účely. charakteristické hodnoty.

1.3. Vytvárame informačný register, ktorý vlastne spája tri objekty:
- Objekt, ku ktorému pripájame mechanizmus charakteristík
- Typové vlastnosti (typ PVC)
- Hodnota charakteristiky (typ - charakteristika, ide o nový typ, ktorý sa objavil v systéme po vytvorení PVC
a popis všetkých možných dátových typov, ktoré môže charakteristická hodnota nadobudnúť).
V informačnom registri uvádzame, že Vlastníkom Charakteristickej hodnoty je Typ charakteristiky (odkaz na parameter výberu), ako aj typové spojenie pre Charakteristickú hodnotu, opäť z Typu charakteristiky.

Ďalšou vlastnosťou je, že pre každý vytvorený typ charakteristiky môžete určiť typ hodnoty charakteristiky, ak nepotrebujete všetky možné typy na popis hodnoty tejto charakteristiky.

2. Použitie PVC na vytvorenie sub-conto mechanizmu pre účtovný register .

2.1. Vytvárame PVC TypesSubconto.

2.2. Vytvoríme podriadený adresár ValuesSubConto (rovnako ako pri charakteristikách, bude obsahovať hodnoty subconto, ak v iných adresároch také nie sú).

2.3. Komunikácia prebieha pomocou účtovej osnovy.

*************************************************************************************************
Zdroje účtovného registra:

Suma - súvaha,
Množstvo - podsúvahové a spojené s účtovným znakom Kvantitatívne

*************************************************************************************************
Virtuálne tabuľky účtovného registra:

Obrat: obrat jedného účtu
TurnoverDtKt: obrat medzi akýmikoľvek dvoma účtami, to znamená všetky rovnaké transakcie za dané obdobie.

*************************************************************************************************
Účtovanie mien v účtovných registroch - ako implementovať:

V účtovom rozvrhu vytvoríme účtovný atribút „mena“.
V účtovnom registri dodatočne vytvárame:
- Dimenzia meny (zákaz prázdnych hodnôt, podsúvahy, účtovný atribút - mena)
- zdroj CurrencyAmount (podsúvahový, účtovný atribút - mena, uloží sumu v mene, teda napríklad 100 USD)
Všetky.

Takže štruktúra registra je:

Miery:
- Mena
Zdroje
- Množstvo
- Suma (suma v rubľoch)
- CurrencyAmount (suma v mene)

Menové účtovníctvo je teda len zdokonalením konvenčného účtovníctva v Bieloruskej republike, nemení podstatu napr.
(tam je ako obvykle suma v rubľoch, bez ohľadu na to, či je účet v cudzej mene alebo nie).
A ak je funkcia menového účtovníctva pre účet vypnutá, potom ide o obvyklú štruktúru Bieloruskej republiky (zdroje - iba množstvo a množstvo).

*************************************************************************************************
Pri nastavovaní parametrov virtuálnej tabuľky na získanie jej časti kladieme podmienky na rozmery, nie na zdroje.

V opačnom prípade nedostaneme časť najnovších, ale posledný záznam so zadanou hodnotou zdroja - nemusí byť posledný v množine dimenzií

*************************************************************************************************
Význam zdroja a podrobnosti v registri výpočtov

Vo výpočtových registroch vytvorenie zdroja umožňuje jeho príjem pri výpočte základne pomocou tohto registra.
A aj v pomere k danému obdobiu sa hodnota zdroja prepočíta (ak sa základné obdobie nezhoduje s periodicitou registra).

A hodnota atribútu je dostupná len v reálnej tabuľke výpočtového registra, nie je dostupná vo virtuálnych tabuľkách.

*************************************************************************************************
Zaškrtávacie políčko "Základné" vo vlastnostiach rozmeru výpočtového registra
Znamená to, že z tejto dimenzie sa v budúcnosti získa základ a slúži na dodatočné indexovanie hodnôt pre toto pole.

*************************************************************************************************
Rozdelenie doby platnosti dovolenky podľa mesiacov pri zaznamenávaní súborov registrových záznamov,
ak je dovolenka uvedená v doklade v jednom riadku na niekoľko mesiacov naraz v jednom riadku:

StartDate of CurrentMonth = Začiatok mesiaca(TexLineMainAccruals.ActionPeriodStart); Aktuálny mesiacKoniecDátum = EndMonth(TexLineMainAccruals.ActionPeriodStart); Aktuálny mesiac = Dátum; WhileDateStartCurrentMonth<= НачалоМесяца(ТекСтрокаОсновныеНачисления.ПериодДействияКонец) Цикл Движение = Движения.ОсновныеНачисления.Добавить(); Движение.Сторно = Ложь; Движение.ВидРасчета = ТекСтрокаОсновныеНачисления.ВидРасчета; Движение.ПериодДействияНачало = Макс(ДатаНачалаТекМесяца, ТекСтрокаОсновныеНачисления.ПериодДействияНачало); Движение.ПериодДействияКонец = КонецДня(Мин(ДатаОкончанияТекМесяца, ТекСтрокаОсновныеНачисления.ПериодДействияКонец)); Движение.ПериодРегистрации = Дата; Движение.Сотрудник = ТекСтрокаОсновныеНачисления.Сотрудник; Движение.Подразделение = ТекСтрокаОсновныеНачисления.Подразделение; Движение.Сумма = 0; Движение.КоличествоДней = 0; Движение.График = ТекСтрокаОсновныеНачисления.График; Движение.Параметр = ТекСтрокаОсновныеНачисления.Параметр; Движение.БазовыйПериодНачало = НачалоМесяца(ДобавитьМесяц(Дата, -3)); Движение.БазовыйПериодКонец = КонецДня(КонецМесяца(ДобавитьМесяц(Дата, -1))); ДатаНачалаТекМесяца = НачалоМесяца(ДобавитьМесяц(ДатаНачалаТекМесяца, 1)); ДатаОкончанияТекМесяца = КонецМесяца(ДатаНачалаТекМесяца); КонецЦикла; КонецЕсли;

*************************************************************************************************
Vytvorenie Ganttovho diagramu:

Na formulár umiestnime prvok typu „Ganttov diagram“, nazveme ho DG, potom vytvoríme príkaz „Generovať“ a do modulu formulára napíšeme:

&Procedúra OnClient Generate(Command) GenerateOnServer(); Koniec procedúry &Na serveri Procedúra GenerateOn Server() DG.Clear(); DG.Update = False; Požiadavka = Nová požiadavka("SELECT |BasicAccrualsActualActionPeriod.Zamestnanec, |BasicAccrualsActualActionPeriod.CalculationType, |BasicAccrualsActualActionPeriod.ActionPeriodStart AS ActionPeriodStart, |ABasicAccrualsAccrualsEnginePeriodA.A. |Registrácia výpočtov.BasicAccruals.ActualPeriodActions AS BasicAccrualsActualPeriodActions |WHERE |BasicAccrualsActualPeriodActions.PeriodActions BETWEEN &StartDate AND &Dátum konca "); Query.SetParameter("StartDate", Period.StartDate); Request.SetParameter("Dátum ukončenia", Period.Dátum ukončenia); Select = Query.Run().Select(); Kým Selection.Next() Loop Point = DG.SetPoint(Selection.Employee); Séria = DG.SetSeries(Selection.CalculationType); Hodnota = DG.GetValue(Bod, Séria); Interval = Value.Add(); Interval.Start = Sample.PeriodActionStart; Interval.End = Sample.ActionPeriodEnd; EndCycle; DG.Update = Pravda; Koniec procedúry

Tu je pre nás dôležitý vlastne len kód v slučke, ostatné veci sú pomocné, dal som len celú implementáciu tejto podúlohy.
V žiadosti je pre nás dôležité, aby bol uvedený zamestnanec, typ platby, dátum začiatku a konca obdobia.
Kód je v skutočnosti veľmi jednoduchý, ľahko zapamätateľný, nezľaknite sa, ak sa zdá byť ťažkopádny

*************************************************************************************************
Spracovanie záznamov „obrátenia“ vo výpočtových úlohách:

V procese spracovania transakcií (modul objektov) vytvoríme všetky pohyby a ak existujú záznamy v iných obdobiach, dostaneme ich takto
(systém ich generuje automaticky – pomáha nám):

Addition Records = Movements.MainAccruals.GetAddition(); // Na získanie sčítania nie je potrebné zaznamenávať pohyby

Pre každú technologickú líniu z cyklu záznamov pridávania
Record = Movements.MainAccruals.Add();
FillPropertyValues(Record, TechString);
Record.RegistrationPeriod = TechString.RegistrationPeriodReversal;
Record.ActionPeriodStart = TechString.ActionPeriodStartReverse;
Record.ActionPeriodEnd = TechString.ActionPeriodEndReversal;
Koniec cyklu

A pri výpočte záznamov vložte kontroly:

Ak TechMotion.Reversal Then
CurrentMovement.Sum = - CurrentMovement.Amount;
koniec Ak;

*************************************************************************************************
Ako určiť, čo je zahrnuté v hlavných časových rozlíšeniach a čo je zahrnuté v dodatočných časových rozlíšeniach vo výpočtových úlohách.

Nie je to však vždy 100% jasné, existujú aj komplikovanejšie prípady, aj keď ich nie je málo
(napríklad bonus, ktorý závisí od počtu pracovných dní v mesiaci - to je ON).

Základné poplatky:
Ak typ výpočtu závisí od harmonogramu (tzn. register informácií s kalendárnymi dátumami), potom ide o hlavné poplatky.

Príklad OH:
- Plat
- Niečo, čo sa počíta z počtu pracovných dní (a na to musíte použiť rozvrh): buď v období platnosti (napríklad plat) alebo v základnom období

Dodatočné poplatky:
Čo sa berie do úvahy buď z naakumulovanej sumy, alebo odpracovaného času (a nie je to norma!), alebo vôbec nezávisí - to je dodatočné. časové rozlíšenie.

Čiže: časové rozlíšenie, na výpočet ktorého sa používa časový štandard (možno aj fakt), je OH a na ktorý nie sú potrebné skutočné údaje alebo vôbec nič, je DN.

Alebo inak povedané:

Ak VR používa časový štandard, potom musí byť pre VR zahrnutá aj doba platnosti.

*************************************************************************************************
Pridajte možnosť otvoriť vstavanú sekciu pomocníka „Práca s referenčnými knihami“ vo forme zoznamu v adresári „Nomenklatúra“.

Spustite príkaz vo formulári:

&OnClient
Postup Pomocník (príkaz)
OpenHelp("v8help://1cv8/EnterprWorkingWithCatalogs");
Koniec procedúry

Čiara rezu definujeme takto:
Prejdite na informácie pomocníka konfiguračného objektu (v konfigurátore), napíšte slovo, vyberte ho, prejdite do ponuky Prvky/Odkaz a vyberte požadovanú časť Pomocníka 1C, po ktorej sa automaticky vloží odkaz. Vyzerá to komplikovane, ale v praxi je to jednoduché.

*************************************************************************************************
Implementácia interakcie medzi formulármi, napríklad výber:

1. Z aktuálneho formulára otvorte požadovaný pomocou metódy „OpenForm()“, pričom ako druhý parameter (ak je to potrebné) odošlete štruktúru s parametrami. Tretí parameter môže odovzdať odkaz na tento formulár - ThisForm.

2. V otvorenom formulári v obslužnom programe „When CreatedOnServer()“ môžeme zachytiť parametre odovzdané v kroku 1 cez „Parameters.[ParameterName]“. Formulár, ktorý inicioval otvorenie tohto formulára, bude prístupný cez identifikátor „Vlastník“ (ak bol, samozrejme, uvedený v kroku 1).

A čo je najdôležitejšie, budú k dispozícii exportné funkcie formulára vlastníka. To znamená, že môžeme zavolať funkciu exportu zdrojového formulára a odovzdať tam niečo ako parameter na spracovanie výberu. A táto funkcia už vyplní to, čo je potrebné v pôvodnom formulári. Existuje len jedno upozornenie - medzi klientskymi procedúrami nemôžete odovzdať tabuľku hodnôt, ale môžeme ju umiestniť do dočasného úložiska a jednoducho odovzdať adresu VX a potom ju extrahovať z VX.

*************************************************************************************************
Životný cyklus parametrov formulára

Všetky parametre prenesené do formulára v čase jeho otvorenia sú viditeľné iba v procedúre „When CreateOnServer“.
Po vytvorení sa všetky parametre zničia a už nie sú dostupné vo formulári.
Výnimkou sú parametre, ktoré sú deklarované v editore formulárov s atribútom „Kľúčový parameter“.
Určujú jedinečnosť formy.
Tento parameter bude existovať dovtedy, kým bude existovať samotný formulár.

*************************************************************************************************
Používanie rozhrania Taxi

Počas vývoja môžete vo vlastnostiach konfigurácie nastaviť obvyklé spravované rozhranie 8.2 - vďaka tomu je všetko výrazne kompaktnejšie a známejšie.
Platí to najmä vtedy, ak si prenajímate na diaľku - rozlíšenie obrazovky je veľmi malé a s rozhraním „taxi“ nie je možné nič robiť.
Keď skončíte, nezabudnite znova zadať „Taxi“!V opačnom prípade vám skúšajúci odpočíta body!

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

PS: E Existujú samostatné štandardné podúlohy, ktoré sa používajú vo všetkých úlohách, a práve tie musíte vedieť vyriešiť (napríklad odpisovanie po dávkach, používanie PVC (no, to je naozaj zriedkavé) a iné). A vo všetkých úlohách sa jednoducho opakujú (niekde sú nejaké podúlohy, inde, len v rôznych kombináciách). Navyše už dávno sľubujú, že vydajú novú kolekciu (ak tak ešte neurobili), v ktorej by malo byť oveľa viac problémov, to znamená, že nemá zmysel memorovať riešenia jednotlivých problémov, má zmysel naučiť sa vyriešiť jednotlivé štandardné čiastkové úlohy, potom vyriešite akýkoľvek problém.

PSS: Kolegovia, ak má niekto ďalšie užitočné informácie o príprave na skúšku a jej absolvovaní, napíšte do komentárov a článok doplníme.