Být ve skupině podle hierarchie 1C 8 Operátor „v hierarchii“ v požadavku. Získání všech rodičů prvku

12.12.2023Nadpis: Bezpečnost

Ildarovič 6489 16.11.12 18:24 Aktuálně k tématu

() Vladimíre! Jsem rád, že jste článku věnovali pozornost, zvláště když jste byli jedni z prvních, kteří tuto techniku viděli (a ocenili) v diskuzi před dvěma lety „Je reálné napsat záludný dotaz“. Na zajímavou otázku jsem nepřišel sám, ale viděl jsem to na fóru. Autorem otázky je Stanislav Sheptalov. Další - 24. 10. 12 stejný (jen si toho všiml, protože přezdívka je jiná) účastník fóra položil podobnou otázku, ale v aplikaci do hierarchie. Ukazuje se, že PRAKTICKÝ problém byl vyřešen. Dále jsem se v souladu s „vědeckým“ přístupem podíval na praktické problémy, kde by se tato technika dala použít. Nalezeno 7 dalších problémů. 5 - v tomto článku. Mezi nimi je problém s cykly ve specifikacích, který jsem dříve slíbil vyřešit Ish_2 jedním dotazem. Myslím, že Ish_2 vás bude schopen přesvědčit o relevanci tohoto úkolu - strávil na něm spoustu času. Řešení je krátké - pár řádků, tudíž mimořádně jasné, formulované neprocedurálním stylem, přes požadavek na výsledek. V článcích a na fóru se objevily další problémy a pro ně byla navržena těžkopádnější řešení. Počkejme si tedy na to, jak často to bude aplikováno. Přesně takovou zpětnou vazbu očekávám – od těch, kteří se o to pokusí.
Mimochodem, o tom, že tento obor matematiky není daleko od praxe a je potřebami pro účetní, svědčí obecný modul „Cost Adjustment“ v BP2, se kterým se právě vrtíme (nestabilní provoz standardního požadavku). Tam mluvíme o přerušení cyklů grafu pohybu položek a sestavení kostry.
Nyní o struktuře databáze „pro konkrétní úkol“. Byla položena otázka ohledně implementace úlohy v 1C, a proto byla úloha vyřešena v 1C. Pokud byste se zeptali, „kterým autobusem se dostanete do knihovny“, a odpověděli byste, že je lepší letět vzducholodí, pak byste prostě nepochopili (možná kromě těch, kteří uvízli v zácpě v Moskvě ). Zpočátku metoda fungovala ve zcela jiném jazyce.
Obecně vás nebudu moci přesvědčit, pokud si myslíte, že architektura platformy 1C není dobrá. Mohu jen vyjádřit svůj názor. Vývoj databázového schématu od nuly pro konkrétní úlohu je drahý. Když to srovnáme se stavebnictvím: 1C jsou panelové výškové budovy - levné bydlení - prostředek hromadné automatizace - ve stísněných podmínkách, ale bez urážky. Jednotlivé organizace si mohou najmout Normana Fostera, aby přesně realizoval jejich požadavky. Zbytek musí používat levné sériově vyráběné projekty – relační DBMS s rigidním objektovým modelem. Navíc znám smutnou zkušenost s používáním Cashe v několika projektech. Očima vývojáře nevypadá vše tak růžově, jak to teoreticky vypadá. Objektový model 1C obstojí ve zkoušce času – „rozsáhlá území jsou zastavěna a obydlena“. Navíc se vyvíjí. V poslední době 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í bezproblémově propojit 1C s jiným DBMS. Takto například vyměňujeme s importovaným ERP.
Ale přesto bych nerad odváděl rozhovor od hlavního tématu – práce s navrženými technikami v podrobných PRAKTICKÝCH úkolech.

Co je adresář 1C a proč je potřeba? V adresáři jsou uloženy podmíněně trvalé informace, tzn. informace, které zůstávají po dlouhou dobu téměř nezměněny. Například adresář „Nomenklatura“ obsahuje seznam prodaného nebo vyrobeného zboží. Adresář může také obsahovat mnoho vlastností popisujících prvek adresáře.

Vezmeme-li pro srovnání pohlaví osoby, pak je seznam omezený a nemění se, takže se pro něj lépe hodí výčet.

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

Podívejme se na všechny jeho záložky.

Základní

Zde je uvedeno jméno (identifikátor v databázi) a synonymum (uživatelské jméno adresáře). Nepovinný komentář je takový, který může vysvětlit účel adresáře nebo popsat jeho vlastnosti.

Hierarchie

Na této záložce můžete nakonfigurovat hloubku vnoření prvků adresáře. Pomocí tohoto nastavení je vhodné rozlišovat a detailovat prvky podle určitých kritérií. Například produkty „Skříně“ jsou v jedné skupině a produkty „Stoly“ jsou v jiné. Ve výchozím nastavení při vytváření adresáře představuje seznam prvků. Pokud zaškrtnete políčko Hierarchický adresář, pak každý prvek může být podřízen jinému prvku (skupině). Níže jsou uvedeny možnosti přizpůsobení této záložky a změny zobrazení v uživatelském režimu.

Typ hierarchie:

Hierarchie skupin a prvků

S tímto nastavením lze prvky vnořovat pouze do skupin (složek).

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

Umístěte skupiny nahoru

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

Omezení počtu úrovní hierarchie

Pokud zde zaškrtávací políčko není zaškrtnuto, je vnořování neomezené.

Pokud je zaškrtávací políčko zaškrtnuté, můžete níže zadat počet úrovní.

Vlastníci

Na záložce vlastníků mohou být uvedeny další adresáře, kterým je tento podřízený. Vztahový diagram podřízených adresářů je podobný diagramu vztahů hierarchického adresáře, pouze zde jiný adresář vystupuje jako nadřazený a nazývá se vlastník. V typických konfiguracích je dobrým příkladem podřízení adresáře „Dohody“ adresáři „Protistrany“, protože Nemůže existovat dohoda, která nepatří žádné protistraně.

Pole "List of Directory Owners" určuje seznam adresářů, které vlastní prvky tohoto adresáře.

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

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

Chcete-li to provést, musíte se podívat na metadata

Toto je HierarchicalDirectory = Metadata.Directories.Counterparties.Hierarchical;

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

Adresáře 1C jsou specializovaný objekt stromu metadat, který slouží k ukládání statických referenčních informací. V typických konfiguracích můžete například vidět následující zobrazení: , Nomenklatura, Zaměstnanci, Dlouhodobý majetek atd. Informace v adresářích se zpravidla často nemění. Adresáře se následně používají téměř ve všech účetních objektech jako účetní oddíl nebo referenční informace.

Níže se podíváme na nastavení a návrh adresáře z konfigurátoru pomocí adresáře „Nomenklatura“ jako příklad.

Základní karta

Záložka „Základní“ uvádí název, synonymum, reprezentaci objektu a popis účelu.

Záložka „Hierarchie adresářů“.

Zde je stanovena hierarchie adresáře.

Hierarchie v 1C 8.3 je dvou typů - “ skupiny a prvky" A " Prvky". Liší se tím, že v prvním případě může být rodičem (složkou) pouze složka (skupina) a ve druhém případě může být rodičem i prvek.

„Umístit skupiny navrch“ - příznak je zodpovědný za zobrazení skupin ve formě seznamu.

Také v nastavení můžete omezit počet skupin v hierarchii adresářů pomocí příslušného nastavení.

Vlastníci Tab

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

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

Údaje Tab

Získejte 267 videolekcí na 1C zdarma:

Nejdůležitější záložka z pohledu programátora. Obsahuje podrobnosti o adresáři.

Adresář 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— atribut typu Boolean označující, zda se jedná o skupinu nebo prvek. Dostupné pouze v hierarchickém adresáři. Poznámka, hodnotu tohoto atributu nelze změnit v režimu 1C: Enterprise.
Kód— rekvizity, typové číslo nebo řetězec (obvykle řetězec). Číslo přidělené automaticky systémem. Obvykle se počítá jako (předchozí kód + 1). Doporučuji použít typ řetězce, protože řazení číselných hodnot nefunguje podle očekávání. Lze použít jako reprezentaci adresáře v seznamu a ve vstupních polích. Obvykle se používá k hledání prvku při zadávání řetězce. Pokud potřebujete odstranit pole Kód, zadejte do délky řádku nulu.
název— povinné údaje, typ řetězce. Maximální délka řádku je 150 znaků. Lze použít jako reprezentaci adresáře v seznamu a ve vstupních polích. Obvykle se používá k hledání prvku při zadávání řetězce. Pokud potřebujete odstranit pole Název, zadejte do délky řádku nulu.
Rodič— atribut typu DirectoryLink.<ИмяТекущегоСправочника>. Dostupné pouze v hierarchickém adresáři. Ukazuje na nadřazeného rodiče v hierarchii. Pokud je prvek nebo skupina v kořenovém adresáři adresáře, je určena hodnota Adresář.<ИмяТекущегоСправочника>.EmptyLink.
Majitel— odkaz na prvek vlastníka aktuálního prvku adresáře (skupiny). Dostupný pouze v podřízeném adresáři 1C.
Odstranění příznaků— rekvizity typu Boolean. Zodpovědný za zobrazení „značky smazání“ v systému. Prvek označený k odstranění je považován za nepoužitelný, ale mohou na něm zůstat staré pohyby dokumentů.
Odkaz— pole typu řetězec. Tento atribut ukládá jedinečný identifikátor objektu – GUID. To, co vidíme v systému na vizuálním zobrazení zvaném „link“, je pouze reprezentace objektu. Nelze změnit.
Předdefinováno— booleovský typ, zobrazuje, zda je prvek předdefinován, o tom později. Nelze změnit.

Záložka „Data“ také uvádí reprezentaci adresáře v systému před verzí 8.2.16, reprezentace mohla být pouze Kód nebo Název. V posledních verzích platformy (od 8.3) lze pohled popsat nezávisle v modulu manažera pomocí obslužné rutiny „ViewReceivingProcessing“.

Karta číslování

Zde můžete určit nastavení adresáře ohledně číslování. Doporučuje se používat automatické číslování. Kontrola 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 zapsat prvek adresáře s nejedinečným kódem, v 1C obdržíte zprávu „Kód adresáře se stal nejedinečným“.

Kódová řada - určuje způsob číslování adresáře můžete zadat číslování adresáře podle vlastníka; Například protistrana „Rohy a kopyta“ bude mít své vlastní číslování smluv – „1, 2, 3“ atd.

Formuláře Tab

Formuláře pro adresář jsou popsány zde. Pokud je konfigurace spuštěna v normálním i spravovaném režimu, pak budou ve výchozím nastavení k dispozici dvě karty s formuláři: „hlavní“ a „rozšířené“ - různé pro normální a spravované aplikace.

Tato stránka má důležitou vlastnost adresáře - „“. Jedná se o velmi pohodlnou funkci 1C 8, která vám umožňuje při vyplňování údajů do vstupního pole nepřecházet do adresáře, ale zadat jeho název, kód atd. a vyberte požadovaný prvek z rozevíracího seznamu. Vypadá to takto:

Ostatní Tab

Na záložce získáte rychlý přístup k hlavním modulům adresáře - objektovému modulu a modulu manažera.

Můžete také definovat seznam předdefinovaných prvků adresáře na stránce. Toto jsou položky, které nelze odstranit v podnikovém režimu. Předdefinované prvky jsou přístupné přímo v konfigurátoru podle názvu, například: Directories.Nomenclature.Service.

Tato záložka také určuje režim blokování – automatický nebo řízený. Použití fulltextového vyhledávání a referenční informace o adresáři dostupné v režimu 1C: Enterprise.

Design „IN HIERARCHY“ v dotazech 1C:Enterprise 8.x umožňuje získat podřízené prvky objektu hierarchické konfigurace podle daného výběru. Dnes se v článku podíváme na příklad jejího použití a také na akce platformy na straně DBMS a její dopad na výkon.

Používání

Podívejme se na jednoduchý příklad použití konstrukce „IN HIERARCHIE“. Při provádění následujícího požadavku budou pro předávanou hodnotu proměnné "Link" získány podřízené prvky hierarchického adresáře "Produkty".

V testovací databázi obsahuje adresář "Produkty" následující testovací data:

Obrázek samozřejmě nezobrazuje všechny položky adresáře. Snímek obrazovky ukazuje pouze strukturu úložiště dat v hierarchickém adresáři. V adresářové tabulce je uloženo 10 skupin nejvyšší úrovně, z nichž každá obsahuje 5 vnořených skupin po 200 prvcích.

Vraťme se k požadavku na test. Odkaz na skupinu "Skupina - 1" předáme parametru "&Odkaz" (viz screenshot výše). Výsledek dotazu pak bude vypadat takto:

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

Syntaxe dotazovacího jazyka 1C:Enterprise klasické SQL v některých ohledech velmi podobné. Ale pro výraz „IN HIERARCHIE“ neexistuje analog v dotazovacím jazyce SQL, protože například pro výraz dotazovacího jazyka platformy „B“ existuje podobný SQL operátor „IN“. Zajímavá je proto práce platformy s DBMS při použití tohoto operátora.

V zákulisí

Pojďme tedy začít. Použijeme například dříve napsaný dotaz pro adresář „Produkty“. Budeme analyzovat akce platformy pro dvě situace:

Předáme skupinu nejvyšší úrovně „Skupina 1“ jako parametr „&Link“ (jako jsme to udělali dříve).
V parametru předáme odkaz na skupinu "Skupina 1 - 1", vnořenou do skupiny nejvyšší úrovně "Skupina 1".

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

1. Nejprve se provede SQL dotaz pro získání odkazu na skupinu adresářů předávanou jako parametr a na všechny podřízené skupiny. Výsledek je umístěn do dočasné tabulky "#tt1".

2. Ve druhé fázi se stejný dotaz provede dvakrát:

Snímek obrazovky obsahuje podrobné komentáře k textu SQL dotazu. 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č se dotaz provádí dvakrát?" Odpověď je jednoduchá: dotaz nejprve obdrží podřízené prvky pro skupiny první úrovně, které jsou již obsaženy v dočasné tabulce (viz bod 1). Druhý dotaz pak načte dílčí prvky pro podskupiny druhé úrovně. Protože na třetí úrovni hierarchie není přítomna žádná skupina adresářů, tento dotaz se již neprovádí.

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

3. Pro získání konečného výsledku dotazu platforma vygeneruje následující SQL dotaz:

Výsledek tohoto konkrétního požadavku může být dále zpracován pomocí algoritmů ve vestavěném jazyce platformy. Záznamy v dočasné tabulce "#tt1" se tedy používají k nastavení podmínky vzorkování z referenční tabulky "_Reference41".

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

Tím je dokončen proces provádění operátoru „IN HIERARCHY“. Dovolte mi připomenout, že uvažovaná sekvence akcí na serveru SQL byla provedena, když jsme předali odkaz skupině nejvyšší úrovně „Skupina - 1“ na požadavek na straně platformy. Jak se ale bude platforma chovat, když předáme odkaz na skupinu druhé úrovně „Skupina - 1 - 1“ jako parametr „&Odkaz“? Vše proběhne stejně, až na následující bod: výše bylo ve druhé fázi provádění SQL dotazů platformou napsáno, že dotaz 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" tomu tak není. Požadavek bude proveden pouze jednou.

Faktem je, že počet požadavků na získání podřízených prvků závisí na počtu skupin v hierarchii. Jinými slovy, pokud úroveň hierarchie prvků obsahuje alespoň jednu skupinu, pak žádost z bodu 2.

Dopad na výkon

Nesprávné použití libovolného operátoru v dotazu může vést k neoptimálnímu výkonu systému. Výjimkou není ani posuzovaný operátor „IN HIERARCHIE“. Musí být používán s opatrností, protože značně komplikuje algoritmus pro provádění SQL dotazů do databáze a tím zvyšuje zatížení serveru DBMS.

Dovolte mi uvést příklad neoptimálního dotazu, který může vést k výše uvedeným smutným důsledkům:

VYBERTE produkty. Odkaz z adresáře. Produkty JAKO Produkty KDE (Produkty. Odkaz V HIERARCHII (& Odkaz) NEBO Produkty. Odkaz V HIERARCHII (& Odkaz1) NEBO Produkty. Odkaz V HIERARCHII (& Odkaz2) )

Jak asi tušíte, požadavek povede ke generování mnoha SQL dotazů, což bude mít za následek snížení výkonu informačního systému.

Udělejte si závěry!

Je na vás, abyste vyvodili závěry. Řeknu jen, že operátor „IN HIERARCHIE“ používá platforma pro systém skládání dat, když podmínky výběru zahrnují „IN GROUP“, „IN GROUP FROM THE LIST“ a další. Myslím, že není třeba vysvětlovat, že při nesprávných manipulacích mohou uživatelé nastavit velmi složité výběry a několikrát zvýšit zatížení serveru 1C a DBMS. Změňme nastavení pouze pro zkušené uživatele.

A samozřejmě při psaní vlastních mechanismů dávejte pozor na operátor „IN HIERARCHIE“. Na jednu stranu velmi pohodlné a na druhou nebezpečné.

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

Získání prvků hierarchického adresáře, které jsou podřízené dané skupině

Pro získání podřízených prvků hierarchického adresáře poskytuje dotazovací jazyk konstrukci IN HIERARCHY. Příklad použití V HIERARCHII:

VYBRAT
Nomenclature.Code,
Nomenklatura.Nákupní cena
Z

V tomto příkladu budou získány všechny záznamy adresáře Nomenclature umístěné ve skupině &Group, včetně jeho samotného, jeho podřízených skupin a prvků patřících do podřízených skupin.

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

VYBRAT
Nomenclature.Code,
Nomenklatura Název AS Název,
Nomenklatura.Nákupní cena
Z
Directory.Nomenclature AS Nomenklatura

KDE
Nomenklatura.Rodič = &Skupina

Tento dotaz vybere skupiny a prvky podřízené skupině s odkazem &Skupina.

Kontrola přítomnosti podřízených prvků prvku adresáře

Chcete-li zkontrolovat přítomnost podřízených záznamů prvku adresáře, můžete použít dotaz podobný uvedenému:

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

If Request.Execute().Empty() Then
Zpráva("Žádné záznamy");
v opačném případě
Zpráva("Záznamy jsou k dispozici");
endIf;

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

Dotazovací jazyk neposkytuje žádné speciální prostředky pro získání všech rodičů prvku. K dokončení úkolu můžete použít hierarchické součty, ale získávání hierarchických součtů je optimalizováno pro vytváření součtů pro velký počet záznamů a není zcela efektivní pro získání rodičů jednoho prvku. Chcete-li efektivněji načíst všechny rodičovské záznamy prvku, doporučuje se procházet jeho rodiče po malých částech. Příklad:

CurrentItemItem = ItemItem;

Zatímco cyklus pravdy
Request.SetParameter("CurrentItemItem", CurrentItemItem);
Výsledek = Query.Run();
If Result.Empty() Then
Přerušit;
endIf;
Selection = Result.Select();
Selection.Next();
For ColumnNumber = 0 By Result.Columns.Quantity() - 1 smyčka
CurrentItemItem = Selection[ColumnNumber];
Přerušit;
v opačném případě
Report(CurrentItemItem);
endIf;
EndCycle;

If CurrentItemItem = Directories.Nomenclature.EmptyLink() Then
Přerušit;
endIf;
EndCycle;

V tomto příkladu jsou všichni rodiče pro odkaz zaznamenaný v proměnné ElementNomenclature zobrazeni v okně servisní zprávy. V cyklu je vybráno 5 spojovacích rodičů.

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

Zobrazení hierarchického adresáře v sestavě

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

VYBRAT
Nomenclature.Code,
Nomenklatura Název AS Název,
Nomenklatura.Nákupní cena
Z
Directory.Nomenclature AS Nomenklatura
SEŘAZENO PODLE
Název HIERARCHIE

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

Aby byly skupiny adresářů umístěny nad prvky, je nutné v tomto požadavku nahradit klauzuli ORDER BY následujícím:

SEŘAZENO PODLE
Nomenklatura. Toto je skupina HIERARCHIE,
název

Výsledek bude stále uspořádán hierarchicky, ale skupiny se zobrazí nad prvky.

Je také možné nahradit nabídku OBJEDNAT DLE možností AUTOMATICKÉ OBJEDNÁVKY. V tomto případě bude výsledek seřazen v souladu s nastavením adresáře, tzn. pokud je v adresáři uvedeno, že skupiny mají být umístěny nad prvky, budou umístěny výše.

Pomocí výsledků je také možné získat hierarchickou strukturu adresáře.

VYBRAT
Nomenclature.Code,
Nomenklatura Název AS Název,
Nomenklatura.Nákupní cena

FROM Directory.Nomenclature AS Nomenklatura

KDE
(Nomenclature.ThisGroup = FALSE)

OBJEDNAT PODLE JMÉNA

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

Chcete-li získat součty podle hierarchie v dotazu, musíte zadat klíčové slovo HIERARCHIE v klauzuli SOFTWARE TOTAL po zadání pole, podle kterého budou součty počítány. Příklad sestavy "Obrat položek" se získáním součtů podle hierarchie:

VYBRAT

Z

Nomenklatura HIERARCHIE

Na základě tohoto požadavku budou spočítány součty nejen pro každou položku, ale také pro skupiny, do kterých ta či ona položka patří.

V případě, že nepotřebujeme součty pro prvky, ale potřebujeme pouze součty pro skupiny, musíme v součtech použít konstrukci POUZE HIERARCHIE. Příklad:

VYBRAT
Účtování nomenklaturyObrat. Nomenklatura AS Nomenklatura,
Účtování pro NomenklaturuObrat.Nomenklatura.Prezentace,
Účtování pro nomenklaturu Obrat. Množství Obrat AS Množství Obrat
Z
Akumulační registr. Číselník Účetnictví. Obrat JAK Číselník ÚčetnictvíObrat
VÝSLEDKY ČÁSTKA (Množství Obrat) PO
POUZE HIERARCHIE nomenklatury

Výsledkem tohoto dotazu budou celkové záznamy pouze pro skupiny položek.