Atrodoties grupā saskaņā ar 1C 8 hierarhiju Operators “in hierarchy” pieprasījumā. Visu elementa vecāku iegūšana

12.12.2023Virsraksts: Drošība

Ildarovičs 6489 16.11.12 18:24 Šobrīd par tēmu

() Vladimirs! Priecājos, ka pievērsāt rakstam uzmanību, jo īpaši tāpēc, ka pirms diviem gadiem diskusijā “Ir reāli uzrakstīt sarežģītu vaicājumu” bijāt viens no pirmajiem, kas ieraudzīja (un novērtēja) šo paņēmienu. Es pats neizdomāju interesantu jautājumu, bet redzēju to forumā. Jautājuma autors ir Staņislavs Šeptalovs. Nākamais - 24.10.2012 tas pats (to tikko pamanīju, jo segvārds ir cits) foruma dalībnieks uzdeva līdzīgu jautājumu, bet piesakoties hierarhijai. Izrādās, ka PRAKTISKS jautājums ir atrisināts. Tālāk, saskaņā ar “zinātnisko” pieeju, es aplūkoju praktiskās problēmas, kur šo tehniku varētu pielietot. Atrastas vēl 7 problēmas. 5 - šajā rakstā. Starp tiem ir problēma par cikliem specifikācijās, ko iepriekš solīju atrisināt Ish_2 ar vienu vaicājumu. Es domāju, ka Ish_2 spēs jūs pārliecināt par šī uzdevuma atbilstību - viņš tam veltīja daudz laika. Risinājums ir īss – dažas rindiņas, tāpēc ārkārtīgi skaidrs, formulēts neprocedūrā stilā, caur prasību pēc rezultāta. Rakstos un forumā tika sastaptas citas problēmas, un tām tika piedāvāti apgrūtinošāki risinājumi. Pagaidīsim kādu laiku, lai redzētu, cik bieži tas tiks lietots. Tieši tādas atsauksmes es gaidu – no tiem, kas mēģinās.
Starp citu, par to, ka šī matemātikas nozare nav tālu no prakses un ir vajadzīga grāmatvežiem, liecina BP2 vispārējais modulis “Izmaksu korekcija”, ar kuru mēs šobrīd pinam (nestabila standarta pieprasījuma darbība). Tur mēs runājam par vienumu kustības grafika ciklu pārtraukšanu un aptveroša koka izveidošanu.
Tagad par datu bāzes struktūru “konkrētam uzdevumam”. Tika uzdots jautājums par uzdevuma izpildi 1C, un tāpēc uzdevums tika atrisināts 1C. Ja jums jautātu "ar kādu autobusu var nokļūt bibliotēkā" un jūs atbildētu, ka labāk ir lidot ar dirižabli, tad jūs vienkārši nesaprastu (varbūt izņemot tos, kuri ir iestrēguši Maskavas sastrēgumā ). Sākotnēji metode darbojās pavisam citā valodā.
Kopumā es nevarēšu jūs pārliecināt, ja jūs domājat, ka 1C platformas arhitektūra nav laba. Varu izteikt tikai savu viedokli. Datu bāzes shēmas izstrāde no jauna konkrētam uzdevumam ir dārga. Ja salīdzinām ar celtniecību: 1C ir paneļu augstceltnes - lēts mājoklis - masu automatizācijas līdzeklis - šauros apstākļos, bet bez aizvainojuma. Atsevišķas organizācijas var nolīgt Norman Foster, lai precīzi īstenotu viņu prasības. Pārējiem ir jāizmanto lēti masveidā ražoti projekti - relāciju DBVS ar stingru objektu modeli. Turklāt esmu iepazinies ar bēdīgo pieredzi, izmantojot Cash vairākos projektos. Izstrādātāja skatījumā viss neizskatās tik rožaini kā teorētiski. 1C objekta modelis iztur laika pārbaudi - “ir apbūvētas un apdzīvotas plašas teritorijas”. Turklāt tas attīstās. Nesen ir parādījusies ārējo datu avotu tehnoloģija. Un, ja kādam uzdevumam ir nepieciešama lielāka reaģētspēja (piemēram, norēķinu sistēmas), tagad varat nemanāmi savienot 1C ar citu DBVS. Piemēram, šādi mēs apmaināmies ar importēto ERP.
Bet tomēr es negribētu sarunu novirzīt no galvenās tēmas - piedāvāto paņēmienu darba detalizētos PRAKTISKAIS uzdevumos.

Kas ir 1C direktorijs un kāpēc tas ir vajadzīgs? Katalogs glabā nosacīti pastāvīgu informāciju, t.i. informācija, kas paliek gandrīz nemainīga ilgu laiku. Piemēram, direktorijā “Nomenklatūra” ir pārdoto vai ražoto preču saraksts. Arī direktorijā var būt daudz rekvizītu, kas apraksta direktorija elementu.

Ja salīdzinājumam ņemam cilvēka dzimumu, tad saraksts ir ierobežots un nemainās, tāpēc tam labāk piemērots uzskaitījums.

Pēc jauna direktorija izveides mēs redzēsim šādu attēlu.

Apskatīsim visas viņa grāmatzīmes.

Pamata

Šeit ir norādīts nosaukums (identifikators datu bāzē) un sinonīms (direktorija lietotāja vārds). Neobligāts komentārs ir tāds, kas var izskaidrot direktorija mērķi vai aprakstīt tā funkcijas.

Hierarhija

Šajā cilnē varat konfigurēt direktorija elementu ligzdošanas dziļumu. Izmantojot šo iestatījumu, ir ērti atšķirt un detalizēt elementus atbilstoši dažiem kritērijiem. Piemēram, produkti “Skapji” ir vienā grupā, bet produkti “Galdi” – citā. Pēc noklusējuma, veidojot direktoriju, tas attēlo elementu saraksts. Ja atzīmējat izvēles rūtiņu Hierarhiskais direktorijs, tad katrs elements var būt pakārtots citam elementam (grupai). Tālāk ir norādītas šīs grāmatzīmes pielāgošanas un displeja maiņas opcijas pielāgotajā režīmā.

Hierarhijas veids:

Grupu un elementu hierarhija

Izmantojot šo iestatījumu, elementus var ligzdot tikai grupās (mapēs).

Šeit, kā redzat, visiem elementiem un grupām ir vienādas ikonas, un jebkuru elementu var ligzdot.

Novietojiet grupas augšpusē

Ja šī izvēles rūtiņa ir atzīmēta, grupas vienmēr būs augšpusē, pretējā gadījumā tās tiks sakārtotas kārtošanas secībā, piemēram, šādi:

Hierarhijas līmeņu skaita ierobežošana

Ja izvēles rūtiņa šeit nav atzīmēta, ligzdošana ir neierobežota.

Ja izvēles rūtiņa ir atzīmēta, zemāk varat norādīt līmeņu skaitu.

Īpašnieki

Uz grāmatzīmes īpašniekiem var norādīt citus direktorijus, attiecībā uz kuriem šis ir pakārtots. Pakārtoto direktoriju attiecību diagramma ir līdzīga hierarhiskā direktorija attiecību diagrammai, tikai šeit cits direktorijs darbojas kā vecāks un tiek saukts par īpašnieku. Tipiskās konfigurācijās labs piemērs ir direktorijas "Līgumi" pakārtošana direktorijai "Darījuma partneri", jo Nevar būt līgums, kas nepieder nevienam darījuma partnerim.

Laukā "Direktoriju īpašnieku saraksts" ir norādīts to direktoriju saraksts, kuriem pieder šī direktorija elementi.

Zemāk laukā “Padotības izmantošana” ir norādīts, kam tiks pakārtoti šī direktorija elementi.

Kā programmatiski noskaidrot, vai direktorijs ir vai nav hierarhisks

Lai to izdarītu, ir jāatsaucas uz metadatiem

Tas ir HierarchicalDirectory = Metadata.Directories.Counterparties.Hierarchical;

Turpinājums sekos...

1C direktoriji ir specializēts metadatu koka objekts, kas kalpo statiskas atsauces informācijas glabāšanai. Piemēram, tipiskās konfigurācijās var redzēt šādus skatus: , Nomenklatūra, Darbinieki, Pamatlīdzekļi utt. Informācija katalogos, kā likums, nemainās bieži. Katalogi pēc tam tiek izmantoti gandrīz visos grāmatvedības objektos kā grāmatvedības sadaļa vai atsauces informācija.

Tālāk mēs aplūkosim direktorija iestatīšanu un noformēšanu no konfiguratora, piemēram, izmantojot direktoriju “Nomenclature”.

Pamata cilne

Cilnē “Pamata” ir norādīts nosaukums, sinonīms, objekta attēlojums un mērķa apraksts.

Cilne "Katalogu hierarhija".

Šeit tiek izveidota direktorija hierarhija.

Hierarhija 1C 8.3 ir divu veidu - “ grupas un elementi" Un " elementi". Tas atšķiras ar to, ka pirmajā gadījumā tikai mape (grupa) var būt vecāks (mape), bet otrajā gadījumā elements var būt arī vecāks.

“Novietot grupas augšpusē” - karogs ir atbildīgs par grupu attēlošanu saraksta formā.

Arī iestatījumos varat ierobežot grupu skaitu direktoriju hierarhijā, izmantojot atbilstošo iestatījumu.

Īpašnieku cilne

Direktoriju var pakārtot citam direktorijam. No 1C 8.3 konfigurēšanas viedokļa tas nozīmē, ka atribūts “Īpašnieks” kļūst obligāts pakārtotajam elementam. Piemērs šādam savienojumam starp katalogiem standarta konfigurācijās “Nomenklatūra - Mērvienības”, “Darījumu partneri – Līgumslēdzēju līgumi”.

Direktorija īpašnieks var būt arī šādi metadatu objekti: , .

Datu cilne

Saņemiet 267 video nodarbības 1C bez maksas:

Vissvarīgākā cilne no programmētāja viedokļa. Tajā ir informācija par direktoriju.

Direktorijā ir standarta detaļu kopa, ko 1C 8.2 programmētājs nav rediģējis, to sarakstu var redzēt, noklikšķinot uz pogas "Standarta informācija":

Es pakavēšos pie katra sīkāk:

Šī grupa— atribūts ar Būla tipu, norādot, vai tā ir grupa vai elements. Pieejams tikai hierarhiskajā direktorijā. Piezīme, šī atribūta vērtību nevar mainīt režīmā 1C: Enterprise.
Kods— rekvizīti, tipa numurs vai virkne (parasti virkne). Numurs, ko sistēma piešķir automātiski. Parasti aprēķina kā (iepriekšējais kods + 1). Es iesaku izmantot virknes veidu, jo skaitlisko vērtību kārtošana nedarbojas, kā paredzēts. Var izmantot kā direktoriju attēlojumu sarakstā un ievades laukos. Parasti izmanto, lai meklētu elementu, ievadot virkni. Ja ir jānoņem lauks Kods, rindas garumā ievadiet nulli.
Vārds— obligātie dati, virknes veids. Maksimālais rindiņas garums ir 150 rakstzīmes. Var izmantot kā direktoriju prezentāciju sarakstā un ievades laukos. Parasti izmanto, lai meklētu elementu, ievadot virkni. Ja jānoņem lauks Nosaukums, rindas garumā ievadiet nulli.
Vecāks— DirectoryLink tipa atribūts.<ИмяТекущегоСправочника>. Pieejams tikai hierarhiskajā direktorijā. Norāda uz augstāko vecāku hierarhijā. Ja elements vai grupa atrodas direktorija saknē, tiek norādīta vērtība Directory.<ИмяТекущегоСправочника>.EmptyLink.
Īpašnieks— saite uz pašreizējā direktorija elementa (grupas) īpašnieka elementu. Pieejams tikai pakārtotajā 1C direktorijā.
Karoga dzēšana— rekvizīti ar Būla tipu. Atbildīgs par “dzēšanas atzīmes” rādīšanu sistēmā. Elements, kas atzīmēts dzēšanai, tiek uzskatīts par nelietojamu, taču tajā var palikt vecas dokumentu kustības.
Saite— virknes tipa lauks. Šis atribūts saglabā unikālu objekta identifikatoru - GUID. Tas, ko mēs redzam sistēmā vizuālā displejā, ko sauc par “saiti”, ir tikai objekta attēlojums. Nevar mainīt.
Iepriekš definēts— Būla tips, parāda, vai elements ir iepriekš definēts, vairāk par to vēlāk. Nevar mainīt.

Cilnē “Dati” ir norādīts arī direktorija attēlojums sistēmā pirms versijas 8.2.16, attēlojums varētu būt tikai kods vai nosaukums. Jaunākajās platformas versijās (sākot no 8.3) skatu var aprakstīt neatkarīgi pārvaldnieka modulī, izmantojot apdarinātāju “ViewReceivingProcessing”.

Numerācijas cilne

Šeit varat norādīt direktorija iestatījumus attiecībā uz numerāciju. Ieteicams izmantot automātisko numerāciju. Unikalitātes kontrole ir karogs, kas vajadzības gadījumā palīdz padarīt kodu unikālu. Ja ar iestatītu karogu mēģināsit uzrakstīt direktorija elementu ar neunikālu kodu, 1C jūs saņemsit ziņojumu “Direktorijas kods ir kļuvis neunikāls”.

Kodu sērija - nosaka, kā numurēt direktoriju, var ievadīt direktorijas numerāciju pēc īpašnieka. Piemēram, darījuma partnerim “Ragi un nagi” būs sava līgumu numerācija - “1, 2, 3” utt.

Veidlapu cilne

Šeit ir aprakstītas direktorija veidlapas. Ja konfigurācija tiek palaista gan parastajā, gan pārvaldītajā režīmā, pēc noklusējuma būs divas cilnes ar veidlapām: “galvenā” un “uzlabotā” - atšķirīgas parastajām un pārvaldītajām lietojumprogrammām.

Šai lapai ir svarīga direktorija iezīme - ““. Šī ir ļoti ērta 1C 8 funkcija, kas ļauj, aizpildot datus ievades laukā, neiedziļināties direktorijā, bet ierakstīt tā nosaukumu, kodu utt. un nolaižamajā sarakstā atlasiet vajadzīgo elementu. Tas izskatās šādi:

Cita cilne

Cilnē varat ātri piekļūt direktorijas galvenajiem moduļiem - objekta modulim un pārvaldnieka modulim.

Varat arī definēt lapā iepriekš definētu direktorija elementu sarakstu. Tie ir vienumi, kurus nevar izdzēst uzņēmuma režīmā. Iepriekš definētiem elementiem var piekļūt tieši konfiguratorā pēc nosaukuma, piemēram: Directories.Nomenclature.Service.

Šī cilne arī nosaka bloķēšanas režīmu - automātisku vai kontrolētu. Pilna teksta meklēšanas izmantošana, kā arī atsauces informācija par direktoriju, kas pieejama 1C: Enterprise režīmā.

Dizains “IN HIERARCHY” 1C:Enterprise 8.x vaicājumos ļauj iegūt hierarhiskas konfigurācijas objekta pakārtotos elementus atbilstoši noteiktai atlasei. Šodien rakstā apskatīsim tās izmantošanas piemēru, kā arī platformas darbības DBVS pusē un ietekmi uz veiktspēju.

Lietošana

Apskatīsim vienkāršu konstrukcijas "HIERARHJĀ" izmantošanas piemēru. Izpildot šādu pieprasījumu, mainīgā "Saite" nodotajai vērtībai tiks iegūti hierarhiskā direktorija "Produkti" pakārtotie elementi.

Testu datubāzē direktorijā "Produkti" ir šādi testa dati:

Protams, attēlā nav redzami visi direktoriju ieraksti. Ekrānuzņēmumā ir redzama tikai datu uzglabāšanas struktūra hierarhiskajā direktorijā. Direktoriju tabulā tiek glabātas 10 augstākā līmeņa grupas, no kurām katrā ir 5 ligzdotas grupas ar 200 elementiem katrā.

Atgriezīsimies pie testa pieprasījuma. Nodosim saiti uz grupu "Grupa - 1" parametram "&Saite" (sk. ekrānuzņēmumu augstāk). Tad vaicājuma rezultāts izskatīsies šādi:

Kā redzam, pieprasījums atgrieza saiti uz pašu augšējo grupu (nodota kā parametrs), kā arī ligzdotās grupas ar tajās esošajiem elementiem. Tādējādi konstrukcijas “HIERARHIJA” izmantošana ļauj ērti iegūt hierarhiski pakārtotus datus.

Vaicājumu valodas 1C:Enterprise sintakse klasiskā SQL dažos aspektos ļoti līdzīgi. Bet izteiksmei “HIERARHIJA” nav analoga SQL vaicājumu valodā, jo, piemēram, platformas “B” vaicājuma valodas izteiksmei ir līdzīgs SQL operators “IN”. Tāpēc platformas darbs ar DBVS, izmantojot šo operatoru, ir interesants.

Aizkadrā

Tātad sāksim. Piemēram, katalogam “Produkti” izmantosim iepriekš uzrakstīto vaicājumu. Mēs analizēsim platformas darbības divās situācijās:

Mēs nodosim augstākā līmeņa grupu “Grupa 1” kā parametru “&Saite” (kā mēs to darījām iepriekš).
Parametrā mēs nodosim saiti uz grupu "Grupa 1 - 1", kas ligzdota augstākā līmeņa grupā "Grupa 1".

Tagad kārtībā. Pirmajā gadījumā platforma SQL serverī veiks šādas darbības:

1. Pirmkārt, tiek izpildīts SQL vaicājums, lai iegūtu saiti uz direktoriju grupu, kas nodota kā parametrs, un visām tās pakārtotajām grupām. Rezultāts tiek ievietots pagaidu tabulā "#tt1".

2. Otrajā posmā viens un tas pats vaicājums tiek izpildīts divas reizes:

Ekrānuzņēmumā ir detalizēti komentāri par SQL vaicājuma tekstu. Īsāk sakot, vaicājums ļauj atlasīt pakārtotos elementus grupām, uz kurām ir atsauces pagaidu tabulā. Jautājums paliek: "Kāpēc vaicājums tiek izpildīts divreiz?" Atbilde šeit ir vienkārša: pirmkārt, vaicājums iegūst pakārtotos elementus pirmā līmeņa grupām, kas jau ir ietvertas pagaidu tabulā (sk. 1. punktu). Pēc tam otrais vaicājums izgūst otrā līmeņa apakšgrupu apakšelementus. Tā kā trešajā hierarhijas līmenī nav nevienas direktoriju grupas, šis vaicājums vairs netiek izpildīts.

Mūsu gadījumā otrais vaicājums atgriezīs tukšu rezultātu, jo ierakstiem, kas atrodas hierarhijas 3. līmenī, nav pakārtotu elementu (tur nav grupu).

3. Lai iegūtu vaicājuma gala rezultātu, platforma ģenerē šādu SQL vaicājumu:

Šī konkrētā pieprasījuma rezultātu var tālāk apstrādāt ar algoritmiem platformas iebūvētajā valodā. Tādējādi pagaidu tabulas "#tt1" ieraksti tiek izmantoti, lai iestatītu izlases nosacījumu no atsauces tabulas "_Reference41".

4. Pēdējā darbībā platforma 1C:Enterprise 8.x izdzēš pagaidu tabulu “#tt1”, jo tā turpmāk vairs netiks izmantota.

Tas pabeidz operatora “IN HIERARCHY” izpildes procesu. Atgādināšu, ka aplūkotā darbību secība SQL serverī tika veikta, kad platformas pusē nodevām saiti uz augstākā līmeņa grupu “Grupa - 1”. Bet kā platforma rīkosies, ja kā parametru “&Saite” nodosim saiti uz otrā līmeņa grupu “Grupa – 1 – 1”? Viss notiks tāpat, izņemot šādu punktu: iepriekš platformas SQL vaicājumu izpildes otrajā posmā tika rakstīts, ka pakārtoto elementu iegūšanas vaicājums tika izpildīts divas reizes - pakārtoto elementu iegūšanas gadījumā grupa "Grupa - 1 - 1" tas tā nav. Pieprasījums tiks izpildīts tikai vienu reizi.

Fakts ir tāds, ka pieprasījumu skaits, lai iegūtu pakārtotos elementus, ir atkarīgs no grupu skaita hierarhijā. Citiem vārdiem sakot, ja elementu hierarhijas līmenī ir vismaz viena grupa, tad pieprasījums no 2. punkta.

Ietekme uz veiktspēju

Jebkura operatora nepareiza izmantošana vaicājumā var izraisīt neoptimālu sistēmas veiktspēju. Aplūkojamais operators “HIERARHIJA” nav izņēmums. Tas jālieto piesardzīgi, jo tas ievērojami sarežģī SQL vaicājumu izpildes algoritmu datu bāzē un tādējādi palielina DBVS servera slodzi.

Ļaujiet man sniegt piemēru neoptimālam vaicājumam, kas var izraisīt iepriekš minētās bēdīgās sekas:

IZVĒLIES produktus. Saite no direktorija. Produkti AS Produkti WHERE (Produkti. Saite HIERARHJĀ (& Saite) VAI Produkti. Saite HIERARHJĀ (& Link1) VAI Produkti. Saite HIERARHJĀ (& Link2) )

Kā jūs varētu nojaust, pieprasījums novedīs pie daudzu SQL vaicājumu ģenerēšanas, kā rezultātā samazināsies informācijas sistēmas veiktspēja.

Izdari savus secinājumus!

Secinājumu izdarīšana ir jūsu ziņā. Atļaušos tikai teikt, ka operatoru “HIERARHJĀ” platforma izmanto datu kompozīcijas sistēmai, kad atlases nosacījumi ietver “IN GROUP”, “IN GROUP FROM THE LIST” un citus. Es domāju, ka nav nepieciešams paskaidrot, ka ar nepareizām manipulācijām lietotāji var iestatīt ļoti sarežģītas atlases un vairākas reizes palielināt 1C servera un DBVS slodzi. Mainīsim iestatījumus tikai pieredzējušiem lietotājiem.

Un, protams, rakstot savus mehānismus, pievērsiet uzmanību operatoram “HIERARHIJA”. Ļoti ērti, no vienas puses, un bīstami, no otras puses.

Šajā sadaļā ir parādīti tipisku problēmu risināšanas piemēri, strādājot ar hierarhiskiem direktorijiem.

Hierarhiskā direktorija elementu iegūšana, kas ir pakārtoti noteiktai grupai

Lai iegūtu hierarhiskā direktorija pakārtotos elementus, vaicājuma valoda nodrošina konstrukciju IN HIERARCHY. Izmantošanas piemērs HIERARHIJAI:

IZVĒLIES
Nomenklatūra. Kods,
Nomenklatūra.PirkumaCena
NO

Šajā piemērā tiks iegūti visi nomenklatūras direktorija ieraksti, kas atrodas grupā &Grupa, ieskaitot sevi, tās pakārtotās grupas un pakārtotajām grupām piederošos elementus.

Ja mūs interesē tikai elementi un grupas, kas atrodas tieši dotajā grupā, tad šādus elementus varam iegūt, iestatot nosacījumu laukā Parent. Piemērs:

IZVĒLIES
Nomenklatūra. Kods,
Nomenclature.Name AS Nosaukums,
Nomenklatūra.PirkumaCena
NO
Directory.Nomenclature AS Nomenklatūra

KUR
Nomenclature.Parent = &Grupa

Šis vaicājums atlasīs grupas un elementi, kas ir pakārtoti grupai ar saiti &Grupa.

Direktorija elementa pakārtoto elementu klātbūtnes pārbaude

Lai pārbaudītu direktorija elementa pakārtoto ierakstu klātbūtni, varat izmantot vaicājumu, kas ir līdzīgs parādītajam:

Šajā piemērā atsauce uz elementu, kuram vēlaties pārbaudīt bērnus, tiek ierakstīta vaicājuma parametrā Parent. Pēc šāda vaicājuma izpildes jums jāpārbauda, vai rezultāts nav tukšs. Ja rezultāts nav tukšs, tad ir pakārtoti ieraksti. Citādi - nē. Piemērs:

Ja Request.Execute().Empty() Tad
Pārskats ("Nav ierakstu");
Citādi
Pārskats ("Pieejamie ieraksti");
endIf;

Visu elementa vecāku iegūšana

Vaicājuma valoda nenodrošina īpašus līdzekļus visu elementa vecāku izgūšanai. Lai pabeigtu uzdevumu, varat izmantot hierarhiskas kopsummas, taču hierarhisko kopsummu iegūšana ir optimizēta, lai izveidotu kopsummas lielam skaitam ierakstu, un tā nav pilnīgi efektīva, lai iegūtu viena elementa vecākus. Lai efektīvāk izgūtu visus elementa vecāku ierakstus, ir ieteicams cilpu cauri elementa vecākiem nelielās porcijās. Piemērs:

CurrentItemItem = ItemItem;

Kamēr patiesības cikls
Request.SetParameter("CurrentItemItem", CurrentItemItem);
Rezultāts = Query.Run();
Ja Result.Empty() Tad
Pārtraukt;
endIf;
Atlase = Result.Select();
Selection.Next();
Kolonnu skaits = 0 pēc rezultāta.Slejas.Daudzums() - 1 cilpa
CurrentItemItem = Atlase[SlejasNumurs];
Pārtraukt;
Citādi
Pārskats(Pašreizējais vienums);
endIf;
EndCycle;

Ja CurrentItemItem = Directories.Nomenclature.EmptyLink() Tad
Pārtraukt;
endIf;
EndCycle;

Šajā piemērā visi ElementNomenclature mainīgajā ierakstītās saites vecākie tiek parādīti pakalpojuma ziņojuma logā. Ciklā tiek atlasīti 5 saišu vecāki.

Ja direktorijā ir ierobežots un mazs līmeņu skaits, tad ir iespējams iegūt visus vecākus ar vienu pieprasījumu bez cilpas.

Hierarhiska direktorija parādīšana pārskatā

Lai pārskatā parādītu hierarhisku direktoriju, vienlaikus saglabājot hierarhiju, ir jāizmanto vaicājums, kas līdzīgs šim:

IZVĒLIES
Nomenklatūra. Kods,
Nomenclature.Name AS Nosaukums,
Nomenklatūra.PirkumaCena
NO
Directory.Nomenclature AS Nomenklatūra
KĀRTOT PĒC
Nosaukums HIERARHIJA

Šis vaicājums atlasa visus ierakstus no direktorija un sakārto tos hierarhijā. Rezultāts tiks sakārtots pēc nosaukuma, ņemot vērā hierarhiju.

Lai direktoriju grupas tiktu novietotas virs elementiem, šajā pieprasījumā ir jāaizstāj klauzula ORDER BY ar šādu:

KĀRTOT PĒC
Nomenklatūra. Šī ir grupas HIERARHIJA,
Vārds

Rezultāts joprojām tiks sakārtots hierarhiski, bet grupas parādīsies virs elementiem.

Piedāvājumu PASŪTĪT PĒC ir iespējams arī aizstāt ar AUTO PASŪTĪJUMU. Šajā gadījumā rezultāts tiks pasūtīts saskaņā ar direktorija iestatījumiem, t.i. ja direktorijā ir norādīts, ka grupām jāatrodas virs elementiem, tad tās atradīsies augstāk.

Izmantojot rezultātus, ir iespējams iegūt arī direktorija hierarhisko struktūru.

IZVĒLIES
Nomenklatūra. Kods,
Nomenclature.Name AS Nosaukums,
Nomenklatūra.PirkumaCena

NO Directory.Nomenclature AS Nomenklatūra

KUR
(Nomenklatūra. ThisGroup = FALSE)

PASŪTĪT PĒC vārda

Kopējo summu iegūšana pēc hierarhijas

Lai vaicājumā iegūtu kopsummas pēc hierarhijas, klauzulā SOFTWARE TOTAL ir jānorāda atslēgvārds HIERARHIJA pēc tam, kad ir norādīts lauks, pēc kura tiks aprēķinātas kopsummas. Pārskata “Preču apgrozījums” piemērs ar kopsummas iegūšanu pēc hierarhijas:

IZVĒLIES

NO

Nomenklatūras HIERARHIJA

Šī pieprasījuma rezultātā tiks aprēķinātas kopsummas ne tikai katrai precei, bet arī grupām, kurām pieder šī vai cita prece.

Gadījumā, ja mums nav vajadzīgas kopsummas elementiem, bet ir vajadzīgas tikai kopsummas grupām, summās ir jāizmanto konstrukcija HIERARCHY ONLY. Piemērs:

IZVĒLIES
Nomenklatūras uzskaiteApgrozījums. Nomenclature AS Nomenklatūra,
Nomenklatūras uzskaiteApgrozījums.Nomenklatūra.Prezentācija,
Nomenklatūras uzskaiteTurnover.QuantityTurnover AS QuantityTurnover
NO
Uzkrājumu reģistrs.Nomenklatūras uzskaite.Apgrozījums KĀ Nomenklatūras uzskaiteApgrozījums
REZULTĀTU SUMMA (DaudzumsApgrozījums) PO
TIKAI nomenklatūras HIERARHIJA

Šī vaicājuma rezultāts būs tikai preču grupu ierakstu kopsumma.