Operátor hierarchie v dotazu. Příklady dotazů pro práci s hierarchickými adresáři Získejte nejvyšší úroveň hierarchie 1c

Ildarovich 6489 16.11.12 18:24 Nyní v tématu

() Vladimíre! Jsem rád, že jste článku věnovali pozornost, zejména proto, že jste byli jedním z prvních, kdo tuto techniku \u200b\u200bviděl (a ocenil) v diskusi „Opravdu napište záludný dotaz“ před dvěma lety. Zajímavá otázka, kterou jsem sám nepřišel, ale viděl jsem ji ve fóru. Autorem otázky je Stanislav Sheptalov. Dále - dne 24.10.12 to samé (jen na to upozornilo, protože přezdívka je jiná) se člen fóra zeptal na podobnou otázku, ale aplikoval se na hierarchii. Ukazuje se, že PRAKTICKÝ problém byl vyřešen. Dále jsem v souladu s „vědeckým“ přístupem zhodnotil praktické problémy, kde lze tuto techniku \u200b\u200bpoužít. Nalezeno dalších 7 problémů. 5 - v tomto článku. Mezi nimi je problém se smyčkami ve specifikacích, které jsem dříve slíbil vyřešit pomocí Ish_2 v jednom dotazu. Myslím, že Ish_2 vás dokáže přesvědčit o naléhavosti tohoto úkolu - strávil nad ním spoustu času. Řešení je krátké - sestává z několika řádků, a proto je extrémně jasné, formulované v neprocesním stylu, prostřednictvím požadavku na výsledek. S dalšími úkoly se setkaly v článcích a na fóru, byla pro ně navržena těžkopádnější řešení. Počkejme tedy chvíli, abychom zjistili, jak často to bude aplikováno. Takovou zpětnou vazbu očekávám - od těch, kteří se o to pokusí.
Mimochodem, o tom, že toto odvětví matematiky není daleko od praxe a účetní ho potřebují, svědčí obecný modul „Úpravy nákladů“ v BP2, s nímž se právě teď pohráváme (nestabilní práce běžného požadavku). Tam mluvíme o rozbití cyklů grafu posunutí nomenklatury a vybudování kostry.
Nyní o struktuře databáze „pro konkrétní úkol“. Otázka byla položena na implementaci úkolu v 1C, a proto byl úkol vyřešen v 1C. Pokud byste se zeptali, „jakým autobusem se můžete dostat do knihovny“ a odpověděli jste, že je lepší létat ve vzducholodi, jednoduše vám to nebude rozumět (snad, kromě těch, kteří jsou v moskevské dopravní zácpě). Metoda původně fungovala ve zcela jiném jazyce.
Obecně vás nemohu přesvědčit, když si myslíte, že architektura platformy 1C je bezcenná. Mohu jen vyjádřit svůj názor. Vývoj schématu databáze od začátku pro konkrétní úkol je nákladný. Srovnáme-li s výstavbou: 1C jsou panelové výškové budovy - levné bydlení - prostředek hromadné automatizace - ve stísněných prostorech, ale neurazí se. Jednotlivé organizace si mohou najmout Normana Fostera, aby splnil jejich přesné požadavky. Zbytek musí použít levné hromadné projekty - relační DBMS s rigidním objektovým modelem. Kromě toho jsem obeznámen se smutnou zkušeností s používáním Caсhe v několika projektech. Z pohledu vývojáře vše nevypadá vůbec tak růžově jako teoreticky. Objektový model 1C obstojí ve zkoušce času - „jsou vybudována a osídlena obrovská území.“ Navíc se vyvíjí. Nedávno se objevila technologie externích zdrojů dat. A pokud některý úkol vyžaduje vyšší reaktivitu (například fakturační systémy), můžete nyní bez problémů dokovat 1C s jiným DBMS. Například jsme to provedli pomocí importního ERP.
Ale i tak bych nerad odklonil rozhovor od hlavního tématu - práce navrhovaných technik v podrobných PRAKTICKÝCH úkolech.

Co je to referenční příručka 1c a k čemu je? Referenční kniha ukládá podmíněně konstantní informace, tj. informace, které se po dlouhou dobu téměř nemění. Například adresář „Nomenklatura“ obsahuje seznam prodaného nebo vyrobeného zboží. Reference také může obsahovat mnoho vlastností popisujících prvek reference.

Pokud vezmeme pro srovnání pohlaví osoby, pak je seznam zde omezený a nezměněný, takže je pro něj lepší výčet.

Po vytvoření nového adresáře uvidíme následující obrázek.

Zvažme všechny jeho záložky.

Hlavní

Zde je uveden název (identifikátor v databázi) a synonymum (vlastní název adresáře). Volitelný komentář je komentář, který může vysvětlit účel příručky nebo popsat její vlastnosti.

Hierarchie

Na této kartě můžete nastavit hloubku vnoření prvků slovníku. Pomocí tohoto nastavení je vhodné rozlišovat a podrobně rozepisovat prvky podle některých kritérií. Například produkty „Skříně“ jsou v jedné skupině a produkty „Tabulky“ v jiné skupině. Ve výchozím nastavení je odkaz vytvořen seznam položek... Pokud zaškrtnete Hierarchické referenční pole, pak lze každý prvek podřídit jinému prvku (skupině). Níže jsou možnosti přizpůsobení této karty a změny zobrazení ve vlastním režimu.

Typ hierarchie:

Hierarchie skupin a prvků

S tímto nastavením mohou být prvky vnořeny pouze do skupin (složek).

Zde, jak vidíte, mají všechny prvky a skupiny stejné ikony a libovolný prvek lze vnořit.

Umístěte skupiny na vrchol

Když je toto políčko zaškrtnuto, skupiny budou vždy nahoře, jinak budou uspořádány v pořadí řazení, například takto:

Omezení počtu úrovní v hierarchii

Pokud toto políčko není zaškrtnuto, je vnoření neomezené.

Pokud je políčko zaškrtnuto, můžete níže určit počet úrovní.

Majitelé

Na záložce majitelé mohou být uvedeny další adresáře, ve vztahu k nimž je to podřízené. Schéma vztahů mezi podřízenými katalogy je podobné schématu vztahů hierarchického katalogu, pouze zde funguje jako nadřazený jiný katalog a nazývá se vlastníkem. V typických konfiguracích je dobrým příkladem podřízenost adresáře „Smlouvy“ adresáři „Dodavatelé“, protože nemůže existovat žádná smlouva, která nepatří žádné protistraně.

V poli „Seznam vlastníků katalogů“ je uveden seznam katalogů, do kterých patří prvky tohoto katalogu.

Níže v poli „Použití podřízenosti“ je uvedeno, čemu budou podřízeny prvky tohoto odkazu.

Jak programově zjistit, zda je adresář hierarchický nebo ne

Chcete-li to provést, musíte odkázat na metadata

It isHierarchicalDirectory \u003d Metadata.Reference.Contractors.Hierarchical;

Pokračování příště ...

Struktura "IN HIERARCHY" v dotazech 1C: Enterprise 8.x vám umožňuje získat podřízené prvky hierarchického konfiguračního objektu podle daného výběru. Dnes v článku budeme uvažovat o příkladu jeho použití, stejně jako o akcích platformy na straně DBMS a jejím dopadu na výkon.

Použitím

Uvažujme o jednoduchém příkladu použití konstrukce „IN HIERARCHY“. Při provádění dalšího dotazu budou získány podřízené prvky hierarchického katalogu „Produkty“ pro předanou hodnotu proměnné „Reference“.

V testovací databázi obsahuje adresář „Products“ následující testovací data:

Na obrázku se samozřejmě nezobrazí všechny položky adresáře. Snímek obrazovky zobrazuje pouze strukturu úložiště dat v hierarchickém adresáři. Vyhledávací tabulka obsahuje 10 skupin nejvyšší úrovně, z nichž každá obsahuje 5 vnořených skupin, každá s 200 prvky.

Vraťme se zpět k testovacímu dotazu. Pojďme předat v parametru „& Link“ odkaz na skupinu „Group - 1“ (viz výše uvedený snímek obrazovky). Výsledek dotazu bude vypadat takto:

Jak vidíme, požadavek vrátil odkaz na samotnou horní skupinu (předanou parametrem), stejně jako vnořené skupiny s prvky v nich. Použití struktury „IN HIERARCHY“ vám tedy umožňuje pohodlně získat hierarchicky podřízená data.

1C Syntaxe jazyka dotazů: Podniky a klasický SQL jsou v některých bodech velmi podobné. Ale pro výraz „IN HIERARCHY“ neexistuje žádný analogický jazyk v dotazovacím jazyce SQL, například například pro výraz dotazovacího jazyka platformy „B“ existuje podobný operátor SQL „IN“. Proto je při použití tohoto operátora zajímavé pracovat s platformou s DBMS.

V zákulisí

Pojďme tedy začít. Jako příklad použijeme dříve napsaný požadavek do adresáře „Products“. Budeme analyzovat akce platformy pro dvě situace:

Jako parametr „& Link“ předáme skupinu nejvyšší úrovně „Group 1“ (stejně jako dříve).
V parametru předáme odkaz na skupinu „Skupina 1–1“ vnořenou do skupiny nejvyšší úrovně „Skupina 1“.

Nyní v pořádku. V prvním případě platforma provede na serveru SQL následující akce:

1. Nejprve se provede dotaz SQL, aby se získal odkaz na referenční skupinu předanou jako parametr a všechny skupiny jí podřízené. Výsledek se umístí do dočasné tabulky „# tt1“.

2. Ve druhém kroku se stejný dotaz provede dvakrát:

Screenshot podrobně popisuje text dotazu SQL. Stručně řečeno, dotaz umožňuje vybrat podřízené prvky pro skupiny, na které se odkazuje v dočasné tabulce. Otázkou zůstává: „Proč je požadavek prováděn dvakrát?“ Zde je odpověď jednoduchá: za prvé, požadavek obdrží podřízené prvky pro skupiny první úrovně, které jsou již obsaženy v dočasné tabulce (viz odstavec 1). Druhý dotaz poté získá podřízené pro podřízené skupiny druhé úrovně. Protože na třetí úrovni hierarchie není k dispozici žádná skupina katalogů, tento dotaz se již neprovádí.

V našem případě druhý dotaz vrátí prázdný výsledek, protože neexistují žádné podřízené prvky pro záznamy umístěné na 3. úrovni hierarchie (nejsou tam žádné skupiny).

3. Chcete-li získat konečný výsledek dotazu, platforma vytvoří následující dotaz SQL:

Výsledek tohoto konkrétního požadavku lze dále zpracovat pomocí algoritmů ve vestavěném jazyce platformy. Záznamy v dočasné tabulce „# tt1“ se tedy používají k nastavení podmínky výběru z vyhledávací tabulky „_Reference41“.

4. V posledním kroku platforma 1C: Enterprise 8.x odstraní dočasnou tabulku „# tt1“, protože již nebude v budoucnu používána.

Tím je dokončen proces provádění operátoru „IN HIERARCHY“. Dovolte mi připomenout, že výše uvedená posloupnost akcí na serveru SQL byla provedena, když jsme předali odkaz na skupinu nejvyšší úrovně „Skupina - 1“ dotazu na straně platformy. Jak se ale bude platforma chovat, když předáme odkaz na skupinu druhé úrovně „Skupina - 1 - 1“ jako parametr „& Link“? Všechno se stane stejným způsobem, s výjimkou následujícího bodu: výše, ve druhé fázi provádění dotazů SQL platformou, bylo napsáno, že požadavek na získání podřízených prvků byl proveden dvakrát - v případě získání podřízených prvků pro skupina „Skupina - 1–1“, není tomu tak ... Žádost bude provedena pouze jednou.

Jde o to, že počet požadavků na podřízené položky závisí na počtu skupin v hierarchii. Jinými slovy, pokud je alespoň jedna skupina obsažena na úrovni hierarchie prvků, pak žádost z bodu 2.

Dopad na výkon

Nesprávné použití jakéhokoli operátora v požadavku může vést k neoptimálnímu výkonu systému. Dotčený operátor „IN HIERARCHY“ není výjimkou. Mělo by se používat opatrně, protože výrazně komplikuje algoritmus pro provádění dotazů SQL proti databázi, a tím zvyšuje zátěž serveru DBMS.

Uvedu příklad neoptimálního požadavku, který může vést k výše uvedeným smutným důsledkům:

VYBERTE produkty. Odkaz z adresáře. Produkty AS Produkty WHERE (Produkty. Reference IN HIERARCHY (& Reference) NEBO Produkty. Reference IN HIERARCHY (& Reference1) NEBO Produkty. Reference IN HIERARCHY (& Reference2))

Jak asi uhodnete, dotaz povede k vytvoření mnoha dotazů SQL, což bude mít za následek snížení výkonu informačního systému.

Vyvodit závěry!

Závěry, které vás učiní. Dovolte mi jen říct, že operátor „IN HIERARCHY“ používá platforma pro systém složení dat, když podmínky výběru zahrnují „IN GROUP“, „IN GROUP FROM LIST“ a další. Myslím, že nestojí za to vysvětlit, že při nesprávné manipulaci mohou uživatelé nasadit velmi složitý výběr a několikrát zvýšit zátěž serveru 1C a DBMS. Změňme nastavení pouze pro pokročilé uživatele.

A samozřejmě při psaní vlastních mechanismů věnujte pozornost operátoru „IN HIERARCHY“. Na jedné straně velmi pohodlné a na druhé nebezpečné.

Tato část ukazuje příklady řešení typických úkolů při práci s hierarchickými adresáři.

Načítání prvků hierarchického adresáře podřízeného dané skupině

Chcete-li získat podřízené prvky hierarchického katalogu, poskytuje dotazovací jazyk konstrukci IN HIERARCHY. Příklad použití IN HIERARCHY:

VYBRAT
Kód nomenklatury,
Nomenklatura. Nákupní cena
Z

Tento příklad načte všechny položky v katalogu Nomenklatury, které jsou ve skupině & Group, včetně samotné, jejích podřízených skupin a prvků patřících do podřízených skupin.

Pokud nás zajímají pouze prvky a skupiny, které jsou přímo v dané skupině, můžeme tyto prvky získat nastavením podmínky v poli Nadřazený. Příklad:

VYBRAT
Kód nomenklatury,
Nomenklatura. Název AS Název,
Nomenklatura. Nákupní cena
Z
Odkaz. Nomenklatura AS nomenklatura

KDE
Nomenclature.Parent \u003d & Group

Tento dotaz vybere skupiny a členy, kteří jsou podřízeni skupině s odkazem & Skupina.

Kontrola, zda položka katalogu obsahuje podřízené prvky

Chcete-li zkontrolovat existenci podřízených záznamů prvku slovníku, můžete použít dotaz podobný tomu, který je uveden:

V tomto příkladu je odkaz na prvek, u kterého chcete zkontrolovat podřízené prvky, zapsán do nadřazeného parametru dotazu. Po provedení takového dotazu musíte zkontrolovat, zda je výsledek prázdný. Pokud výsledek není prázdný, pak existují podřízené záznamy. Jinak ne. Příklad:

If Query.Run (). Empty () Then
Zpráva („Žádné záznamy“);
v opačném případě
Zpráva („Existují záznamy“);
EndIf;

Získání všech rodičů prvku

V dotazovacím jazyce neexistují žádné speciální prostředky k získání všech rodičů prvku. K dokončení úkolu můžete použít hierarchické součty, avšak získání hierarchických součtů je optimalizováno pro vytváření součtů velkého počtu záznamů a není tak efektivní pro získání rodičů jedné položky. Pro efektivnější načítání všech nadřazených záznamů prvku se doporučuje iterovat přes jeho rodiče ve smyčce v malých částech. Příklad:

CurrentNomenclatureItem \u003d NomenclatureItem;

Až do cyklu pravdy
Query.SetParameter ("CurrentNomenclatureItem", CurrentNomenclatureItem);
Výsledek \u003d Query.Run ();
If Result.Empty () Then
Přerušit;
EndIf;
Výběr \u003d Výsledek.Select ();
Sample.Next ();
Pro číslo sloupce \u003d 0 podle Result.Columns.Number () - 1 cyklus
CurrentNomenclatureItem \u003d výběr [číslo_sloupce];
Přerušit;
v opačném případě
Zpráva (CurrentNomenclatureItem);
EndIf;
Konec cyklu;

If CurrentNomenclatureElement \u003d Directories.Nomenclature.EmptyRef () Then
Přerušit;
EndIf;
Konec cyklu;

V tomto příkladu jsou všichni rodiče zobrazeni v okně zprávy služby pro odkaz zapsaný do proměnné ElementNomenclature. Cyklus vybere 5 rodičů odkazu.

Pokud je počet úrovní v adresáři omezený a malý, je možné získat všechny rodiče v jednom požadavku bez smyčky.

Výstup hierarchického adresáře do sestavy

Chcete-li zobrazit hierarchický katalog v sestavě při zachování hierarchie, musíte použít dotaz podobný tomuto:

VYBRAT
Kód nomenklatury,
Nomenklatura. Název AS Název,
Nomenklatura. Nákupní cena
Z
Odkaz. Nomenklatura AS nomenklatura
SEŘAZENO PODLE
Název HIERARCHY

Tento dotaz vybere všechny záznamy z adresáře a seřadí je podle hierarchie. Výsledek bude seřazen podle názvu s přihlédnutím k hierarchii.

Aby mohly být skupiny adresáře umístěny nad prvky, je nutné v tomto požadavku nahradit návrh OBJEDNAT SOFTWAREM tímto:

SEŘAZENO PODLE
Toto je skupina HIERARCHY,
název

Výsledek bude stále seřazen v hierarchii, ale skupiny se objeví nad položkami.

Je také možné nahradit nabídku OBJEDNACÍ SOFTWARE nabídkou AUTO OBJEDNÁVKU. V takovém případě bude výsledek objednán v souladu s nastavením referenční knihy, tj. pokud referenční kniha naznačuje, že skupiny by měly být umístěny nad prvky, budou umístěny výše.

Je také možné získat hierarchickou strukturu referenční knihy pomocí součtů.

VYBRAT
Kód nomenklatury,
Nomenklatura. Název AS Název,
Nomenklatura. Nákupní cena

FROM Reference. Nomenklatura AS nomenklatura

KDE
(Nomenclature ThisGroup \u003d FALSE)

OBJEDNAT PODLE JMÉNA

Získávání součtů podle hierarchie

Chcete-li v dotazu získat součty podle hierarchie, musíte po zadání pole, podle kterého se součty vypočítají, zadat v klauzuli TOTALS BY klíčové slovo HIERARCHY. Příklad sestavy „Obrat zboží“ s příjmem součtů podle hierarchie:

VYBRAT

Z

Nomenklatura HIERARCHY

V důsledku tohoto požadavku budou součty vypočítány nejen pro každou položku, ale také pro skupiny, do kterých tato nebo tato položka patří.

V případě, že nepotřebujeme součty podle prvků, ale pouze součty podle skupin, musíme použít konstrukci POUZE HIERARCHY v součtech. Příklad:

VYBRAT
Účetní nomenklaturaTurnovers.Nomenklatura AS nomenklatura,
Účetní nomenklaturaTurnovers.Nomenklatura.Prezentace,
AccountingNomenclatureTurnover.QuantityTurnover AS QuantityTurnover
Z
Accumulation Register.AccountingNomenclature.Turnovers AS NomenclatureAccountingTurnovers
CELKEM SUM (NumberTurnover) PODLE
Nomenklatura POUZE HIERARCHIE

V důsledku tohoto požadavku budou k dispozici souhrnné záznamy pouze pro skupiny položek.

Odkazy 1C - specializovaný objekt stromu metadat, který slouží k ukládání statických informací referenční povahy. Například v typických konfiguracích můžete vidět následující zobrazení :, Nomenklatura, Zaměstnanci, Dlouhodobý majetek atd. Informace v příručkách se zpravidla často nemění. Referenční knihy se dále používají téměř ve všech účetních objektech jako účetní část nebo referenční informace.

Níže zvážíme nastavení a návrh referenční knihy z konfigurátoru na příkladu referenční příručky „Nomenklatura“.

Karta Základní

Na kartě „Obecné“ můžete určit název, synonymum, prezentaci objektů, popis účelu.

Reference Hierarchie Tab

Zde je stanovena hierarchie referenční knihy.

V 1C 8.3 existují dva typy hierarchie - " skupiny a prvky"A" elementy". Liší se tím, že v prvním případě může být rodič (složka) pouze složka (skupina) a ve druhém případě může být rodič také prvek.

„Umístit skupiny na začátek“ - příznak je odpovědný za zobrazení skupin ve formě seznamu.

Také v nastavení můžete omezit počet skupin v hierarchii adresářů odpovídajícím nastavením.

Karta Vlastníci

Adresář může být podřízen jinému adresáři. Z hlediska konfigurace 1C 8.3 to znamená, že atribut „Vlastník“ se stává povinným pro podřízený prvek. Příklad takového propojení mezi adresáři ve standardních konfiguracích „Nomenklatura - měrné jednotky“, „Protistrany - Smlouvy protistran“.

Vlastníci adresáře mohou být také následující objekty metadat:,.

Karta Data

Získejte zdarma 267 1C videonávodů:

Nejdůležitější karta z pohledu programátora. Jsou v něm uvedeny podrobnosti o referenční příručce.

Referenční kniha obsahuje sadu standardních podrobností, které programátor 1C 8.2 neupravuje, jejich seznam lze zobrazit kliknutím na tlačítko „Standardní podrobnosti“:

U každého se budu zabývat podrobněji:

Tato skupina - rekvizity typu boolean označující, zda se jedná o skupinu nebo prvek. K dispozici pouze v hierarchickém odkazu. Poznámka, hodnotu této proměnné nelze změnit v režimu 1C: Enterprise.
Kód - atribut, číslo typu nebo řetězec (obvykle řetězec). Číslo přidělené systémem automaticky. Obvykle se počítá jako (předchozí kód + 1). Doporučuji použít typ řetězce, protože třídění číselných hodnot se nedělá podle očekávání. Lze použít jako vyhledávací pohled v seznamu a ve vstupních polích. Obvykle se používá k hledání položky při psaní podle řetězce. Pokud potřebujete odstranit pole Kód, zadejte v délce řádku nulu.
název - Požadovaný atribut, typ řetězce. Maximální délka řádku je 150 znaků. Lze použít jako vyhledávací pohled v seznamu a ve vstupních polích. Obvykle se používá k hledání položky při psaní podle řetězce. Pokud potřebujete odebrat pole Název, zadejte v délce řádku nulu.
Rodič - atribut typu ReferenceLink.<ИмяТекущегоСправочника>... K dispozici pouze v hierarchickém odkazu. Označuje nadřazeného rodiče v hierarchii. Pokud je prvek nebo skupina v kořenovém adresáři adresáře, je zadána hodnota adresáře.<ИмяТекущегоСправочника>.EmptyRef.
Majitel - odkaz na vlastníka prvku aktuálního prvku (skupiny) katalogu. K dispozici pouze v podřízené příručce 1C.
Značka smazání - booleovský atribut. Odpovídá za zobrazení „značky pro odstranění“ v systému. Prvek označený k odstranění je považován za nepoužitelný, ale staré pohyby v dokumentech na něm mohou zůstat.
Odkaz - pole typu řetězce. Tento atribut ukládá jedinečný identifikátor objektu - GUID. To, co vidíme v systému na vizuálním displeji pod názvem „link“, je pouze reprezentace objektu. Nelze změnit.
Předdefinováno - typ boolean, zobrazí, zda je prvek předdefinován, o tom později. Nelze změnit.

Záložka „Data“ také označuje pohled na referenci v systému, před verzí 8.2.16 mohl být pohled pouze Kód nebo Jméno. V novějších verzích platformy (počínaje verzí 8.3) lze pohled popsat samostatně v modulu správce pomocí obslužné rutiny „ViewGetProcessing“.

Karta Číslování

Zde můžete určit nastavení referenční knihy z hlediska číslování. Doporučuje se používat automatické číslování. Řízení jedinečnosti je příznak, který v případě potřeby pomáhá učinit kód jedinečným. Pokud se s nastaveným příznakem pokusíte napsat položku adresáře s nejedinečným kódem, v 1C se zobrazí zpráva „Kód adresáře se stal nejedinečným.“

Série kódů - určuje, jak číslovat adresář, můžete zadat číslování adresáře v kontextu vlastníka. Například protistrana „Rohy a kopyta“ bude mít své vlastní číslování smluv - „1, 2, 3“ atd.

Karta Formuláře

Formuláře pro referenci jsou zde popsány. Pokud je konfigurace spuštěna v normálním i spravovaném režimu, budou ve výchozím nastavení dvě karty s formuláři: „hlavní“ a „další“ - odlišné pro běžné a spravované aplikace.

Na této stránce je důležitá vlastnost příručky - „“. Jedná se o velmi pohodlnou funkci 1C 8, která umožňuje při vyplňování údajů ve vstupním poli nevstupovat do adresáře, ale zadávat jeho název, kód atd. a vyberte požadovanou položku z rozevíracího seznamu. Vypadá to takto:

Karta Jiné

Na kartě získáte rychlý přístup k hlavním modulům příručky - modulu objektu a modulu správce.

Na stránce můžete také definovat seznam předdefinovaných položek katalogu. Jedná se o položky, které nelze odstranit v režimu Enterprise. K předdefinovaným prvkům lze přistupovat přímo v konfigurátoru podle názvu, například: Directories.Nomenclature.Service.

Tato záložka také definuje režim blokování - automatický nebo řízený. Pomocí fulltextového vyhledávání a referenčních informací o příručce dostupných v režimu 1C: Enterprise.